* git fetch <remote> <branch> behaves weirdely when run in a worktree @ 2018-09-23 20:09 Kaartic Sivaraam 2018-09-24 15:17 ` Duy Nguyen 2018-09-26 4:46 ` Kaartic Sivaraam 0 siblings, 2 replies; 12+ messages in thread From: Kaartic Sivaraam @ 2018-09-23 20:09 UTC (permalink / raw) To: Git Users Hi, I was actually trying to automae the building and installation of Git source code to reduce my burden. I tried to automate it with the help of a script that runs daily via cron and a separate worktree used only by the build script.y run The script typically fetches new changes for the next branch by running the following in the build worktree (which is not the main worktree): $ git fetch origin next I thought that would result in FETCH_HEAD pointing to the latest changes for origin/next if the command succeeded. Unfortunately, it seems to be behaving weirdely when run in a worktree. It sems to be behaving as if I ran 'git fetch origin'. To add to that confusion when I run $ cat $MAIN_WORKTREE/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD it seems to be printing the info about the remote refs once and then if I run it again immediately nothing is printed. If I repeat it again, info about remote refs is printed but this time the info about the remote refs is printed thrice. This happens randomly. Sample output: 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of https://github.com/git/git 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of https://github.com/git/git 53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of https://github.com/git/git 53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of https://github.com/git/git 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD 53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' of https://github.com/git/git 150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' of https://github.com/git/git 01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of https://github.com/git/git 7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of https://github.com/git/git 722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of https://github.com/git/git 'git fetch <remote> <branch>' behaves correctly in the main worktree. Why is this weirdness happening when run in other worktrees? Why isn't 'git fetch <remote> <branch> not fetching the changes for just the specified branch? Am I missing something? -- Sivaraam ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-09-23 20:09 git fetch <remote> <branch> behaves weirdely when run in a worktree Kaartic Sivaraam @ 2018-09-24 15:17 ` Duy Nguyen 2018-09-25 18:44 ` Kaartic Sivaraam 2018-09-26 4:46 ` Kaartic Sivaraam 1 sibling, 1 reply; 12+ messages in thread From: Duy Nguyen @ 2018-09-24 15:17 UTC (permalink / raw) To: Kaartic Sivaraam; +Cc: Git Mailing List On Sun, Sep 23, 2018 at 10:19 PM Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote: > > Hi, > > I was actually trying to automae the building and installation of Git > source code to reduce my burden. I tried to automate it with the help > of a script that runs daily via cron and a separate worktree used only > by the build script.y run > > The script typically fetches new changes for the next branch by running > the following in the build worktree (which is not the main worktree): > > $ git fetch origin next > > I thought that would result in FETCH_HEAD pointing to the latest > changes for origin/next if the command succeeded. > > Unfortunately, it seems to be behaving weirdely when run in a worktree. > It sems to be behaving as if I ran 'git fetch origin'. To add to that > confusion when I run > ... > Why is this weirdness happening when run in other worktrees? > > Why isn't 'git fetch <remote> <branch> not fetching the changes for > just the specified branch? > > Am I missing something? Yes, some bugs. It behaves correctly for me. There must be something strange that triggers this. What's your "git worktree list" (iow anything strange there, duplicate worktrees perhaps)? Also please try "git fetch" again with GIT_TRACE=1 and GIT_TRACE_SETUP=1. Hopefully we could catch something with that. -- Duy ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-09-24 15:17 ` Duy Nguyen @ 2018-09-25 18:44 ` Kaartic Sivaraam 2018-09-25 21:40 ` Junio C Hamano 0 siblings, 1 reply; 12+ messages in thread From: Kaartic Sivaraam @ 2018-09-25 18:44 UTC (permalink / raw) To: Duy Nguyen; +Cc: Git Mailing List On Mon, 2018-09-24 at 17:17 +0200, Duy Nguyen wrote: > On Sun, Sep 23, 2018 at 10:19 PM Kaartic Sivaraam > <kaartic.sivaraam@gmail.com> wrote: > > Yes, some bugs. It behaves correctly for me. There must be something > strange that triggers this. What's your "git worktree list" (iow > anything strange there, duplicate worktrees perhaps)? Nothing seems strange in the list. $ git worktree list $COMMON_ROOT/git 01d371f741 (detached HEAD) $COMMON_ROOT/git-next cfa73bbfcb (detached HEAD) $COMMON_ROOT/git-next-build-automate 01d371f741 (detached HEAD) $COMMON_ROOT/git-pu 363c5c06bb (detached HEAD) Note: I sanitized the path in which the git worktrees (including the main worktree) is present as $COMMON_ROOT. > Also please try > "git fetch" again with GIT_TRACE=1 and GIT_TRACE_SETUP=1. Hopefully we > could catch something with that. $ GIT_TRACE_SETUP=1 GIT_TRACE=1 git fetch origin next 23:10:26.049785 trace.c:377 setup: git_dir: $COMMON_ROOT/git/.git/worktrees/git-next-build-automate 23:10:26.049868 trace.c:378 setup: git_common_dir: $COMMON_ROOT/git/.git 23:10:26.049901 trace.c:379 setup: worktree: $COMMON_ROOT/git-next-build-automate 23:10:26.049922 trace.c:380 setup: cwd: $COMMON_ROOT/git-next-build-automate 23:10:26.049941 trace.c:381 setup: prefix: (null) 23:10:26.049955 git.c:415 trace: built-in: git fetch origin next 23:10:26.051033 run-command.c:637 trace: run_command: git-remote-https origin https://github.com/git/git.git 23:10:28.366526 run-command.c:637 trace: run_command: git rev-list --objects --stdin --not --all --quiet 23:10:28.400979 run-command.c:637 trace: run_command: git rev-list --objects --stdin --not --all --quiet 23:10:28.402745 trace.c:377 setup: git_dir: $COMMON_ROOT/git/.git/worktrees/git-next-build-automate 23:10:28.402787 trace.c:378 setup: git_common_dir: $COMMON_ROOT/git/.git 23:10:28.402793 trace.c:379 setup: worktree: $COMMON_ROOT/git-next-build-automate 23:10:28.402798 trace.c:380 setup: cwd: $COMMON_ROOT/git-next-build-automate 23:10:28.402802 trace.c:381 setup: prefix: (null) 23:10:28.402815 git.c:415 trace: built-in: git rev-list --objects --stdin --not --all --quiet From https://github.com/git/git * branch next -> FETCH_HEAD 23:10:28.437350 run-command.c:1553 run_processes_parallel: preparing to run up to 1 tasks 23:10:28.437481 run-command.c:1585 run_processes_parallel: done 23:10:28.437763 run-command.c:637 trace: run_command: git gc --auto 23:10:28.439608 trace.c:377 setup: git_dir: $COMMON_ROOT/git/.git/worktrees/git-next-build-automate 23:10:28.439655 trace.c:378 setup: git_common_dir: $COMMON_ROOT/git/.git 23:10:28.439667 trace.c:379 setup: worktree: $COMMON_ROOT/git-next-build-automate 23:10:28.439677 trace.c:380 setup: cwd: $COMMON_ROOT/git-next-build-automate 23:10:28.439687 trace.c:381 setup: prefix: (null) 23:10:28.439699 git.c:415 trace: built-in: git gc --auto HTH, Sivaraam ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-09-25 18:44 ` Kaartic Sivaraam @ 2018-09-25 21:40 ` Junio C Hamano 2018-09-26 3:37 ` Kaartic Sivaraam 0 siblings, 1 reply; 12+ messages in thread From: Junio C Hamano @ 2018-09-25 21:40 UTC (permalink / raw) To: Kaartic Sivaraam; +Cc: Duy Nguyen, Git Mailing List Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes: >> Also please try >> "git fetch" again with GIT_TRACE=1 and GIT_TRACE_SETUP=1. Hopefully we >> could catch something with that. > > $ GIT_TRACE_SETUP=1 GIT_TRACE=1 git fetch origin next > 23:10:26.049785 trace.c:377 setup: git_dir: $COMMON_ROOT/git/.git/worktrees/git-next-build-automate > ... > 23:10:28.402815 git.c:415 trace: built-in: git rev-list --objects --stdin --not --all --quiet > From https://github.com/git/git > * branch next -> FETCH_HEAD > 23:10:28.437350 run-command.c:1553 run_processes_parallel: preparing to run up to 1 tasks > ... That looks like fetching only the 'next' branch and nothing else to me. Perhaps your script is referring to a variable whose assignment is misspelled and invoking git fetch $origin $branch and you are expecting the $branch variable to have string 'next' but due to some bugs it is empty somehow? That explains why sometimes (i.e. when $branch does not get the value you expect it to have) the script fetches everything and some other times (i.e. when $branch does get the right value) the script fetches only the named branch. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-09-25 21:40 ` Junio C Hamano @ 2018-09-26 3:37 ` Kaartic Sivaraam 0 siblings, 0 replies; 12+ messages in thread From: Kaartic Sivaraam @ 2018-09-26 3:37 UTC (permalink / raw) To: Junio C Hamano; +Cc: Duy Nguyen, Git Mailing List On 26 September 2018 03:10:17 GMT+05:30, Junio C Hamano <gitster@pobox.com> wrote: > > That looks like fetching only the 'next' branch and nothing else to > me. > Interesting. > Perhaps your script is referring to a variable whose assignment is > misspelled and invoking > > git fetch $origin $branch > > and you are expecting the $branch variable to have string 'next' but > due to some bugs it is empty somehow? That explains why sometimes > (i.e. when $branch does not get the value you expect it to have) the > script fetches everything and some other times (i.e. when $branch > does get the right value) the script fetches only the named branch. Noce guees but I should have made this clear. The weirdness I described in my initial mail happens when I run "git fetch origin next" manually in the terminal. The script only helped me identity that there was an issue as it was automatically building the wrong version of Git. It was building and installing the current 'origin/maint' when I wrote it for building origin/next. I could easily identify the difference as 'origin/maint' was at v2.18 while 'origin/next' was at v2.19 when I notived this issue. Also the script doesn't depend on any variables for the branch name. I've hardcoded the 'next' branch into it. For the sake of reference, I've attached the script inline at the end of this mail. Note that I've sanitized the path in which the worktree exists as $COMMON_ROOT. I did not notice this weirdness in another PC. But, this happens in all the worktrees other than the main worktree in my laptop. I'm not sure what I'm doing weirdly that might have caused this issue. I'm not sure whether I mentioned this before I'm currently using a manually built version of Git. It was built from origin/next pointing at 01d371f741. But this also happens in Git v2.18.0 that comes via the pacakge manager of my operating system (Debian testing). -- Sivaraam #!/bin/sh # # A script for the cron job that automatically fetches # updates for the 'next' branch of Git and builds and # installs the binary from source. # # The build succeeds only if the config.mak is present # in the directory with appropriate configuration. # # The binary is installed into the default location if # a prefix is not specified in the config.mak file. # Bringing the binary into use is in the hands of the user. # Hint: A bash alias might help. GIT_NEXT_BUILD_AUTOMATE_DIR='$COMMON_ROOT/git-next-build-automate' LOG_FILE="$GIT_NEXT_BUILD_AUTOMATE_DIR/GIT-NEXT-INSTALLATION-LOG.txt" LOG_MSG_COMMON="installation of git 'next' build on $(date)" if cd "$GIT_NEXT_BUILD_AUTOMATE_DIR" then # Fetch the remote changes if git fetch origin next && git checkout -f FETCH_HEAD then if make install then GIT_NEXT_BUILD_STATUS=0 else GIT_NEXT_BUILD_STATUS=1 fi else GIT_NEXT_BUILD_STATUS=1 fi else GIT_NEXT_BUILD_STATUS=1 fi if test $GIT_NEXT_BUILD_STATUS -eq 0 then echo "SUCCESS: $LOG_MSG_COMMON" >>"$LOG_FILE" else echo "FAILURE: $LOG_MSG_COMMON" >>"$LOG_FILE" fi ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-09-23 20:09 git fetch <remote> <branch> behaves weirdely when run in a worktree Kaartic Sivaraam 2018-09-24 15:17 ` Duy Nguyen @ 2018-09-26 4:46 ` Kaartic Sivaraam 2018-09-26 15:24 ` Duy Nguyen 1 sibling, 1 reply; 12+ messages in thread From: Kaartic Sivaraam @ 2018-09-26 4:46 UTC (permalink / raw) To: Git Users; +Cc: Junio C Hamano, Duy Nguyen Hi, I just wanted make a point a little more clear. See comment inline. On 24 September 2018 01:39:26 GMT+05:30, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote: > To add to that >confusion when I run > > $ cat $MAIN_WORKTREE/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD > >it seems to be printing the info about the remote refs once and then if >I run it again immediately nothing is printed. If I repeat it again, >info about remote refs is printed but this time the info about the >remote refs is printed thrice. This happens randomly. Sample output: > > 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD >53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' >of https://github.com/git/git >150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' >of https://github.com/git/git >01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of >https://github.com/git/git >7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of >https://github.com/git/git >722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of >https://github.com/git/git > 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD > 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD > 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD >53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' >of https://github.com/git/git >150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' >of https://github.com/git/git >01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of >https://github.com/git/git >7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of >https://github.com/git/git >722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of >https://github.com/git/git >53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' >of https://github.com/git/git >150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' >of https://github.com/git/git >01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of >https://github.com/git/git >7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of >https://github.com/git/git >722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of >https://github.com/git/git >53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' >of https://github.com/git/git >150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' >of https://github.com/git/git >01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of >https://github.com/git/git >7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of >https://github.com/git/git >722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of >https://github.com/git/git > 01:23 $ cat ../git/.git/worktrees/$BUILD_WORKTREE/FETCH_HEAD >53f9a3e157dbbc901a02ac2c73346d375e24978c not-for-merge branch 'maint' >of https://github.com/git/git >150f307afc13961b0322ad0e7205a7b193368586 not-for-merge branch 'master' >of https://github.com/git/git >01d371f741e6f0b0076d9ed942d99bdb23757eac not-for-merge branch 'next' of >https://github.com/git/git >7a81cbc028be113058e0b55062706ec6de62ed94 not-for-merge branch 'pu' of >https://github.com/git/git >722746685bce03f223ed75febe312495e6c139da not-for-merge branch 'todo' of >https://github.com/git/git > This is the most interesting part of the issue. I **did not** run 'git fetch ...' in between those cat commands. I was surprised by how the contents of FETCH_HEAD are changing without me spawning any git processes that might change it. Am I missing something here? As far as i could remember, there wasn't any IDE running that might automatically spawn git commands especially in that work tree. Weird. -- Sivaraam Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-09-26 4:46 ` Kaartic Sivaraam @ 2018-09-26 15:24 ` Duy Nguyen 2018-09-26 16:09 ` Duy Nguyen 0 siblings, 1 reply; 12+ messages in thread From: Duy Nguyen @ 2018-09-26 15:24 UTC (permalink / raw) To: Kaartic Sivaraam; +Cc: Git Mailing List, Junio C Hamano On Wed, Sep 26, 2018 at 6:46 AM Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote: > This is the most interesting part of the issue. I **did not** run 'git fetch ...' in between those cat commands. I was surprised by how the contents of FETCH_HEAD are changing without me spawning any git processes that might change it. Am I missing something here? As far as i could remember, there wasn't any IDE running that might automatically spawn git commands especially in that work tree. Weird. Another possibility is FETCH_HEAD is somehow a symlink (or the whole worktrees/$BUILD_WORKTREE is a symlink) and is accidentally shared with some other repos/worktrees. -- Duy ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-09-26 15:24 ` Duy Nguyen @ 2018-09-26 16:09 ` Duy Nguyen 2018-09-26 17:05 ` Junio C Hamano 0 siblings, 1 reply; 12+ messages in thread From: Duy Nguyen @ 2018-09-26 16:09 UTC (permalink / raw) To: Kaartic Sivaraam; +Cc: Git Mailing List, Junio C Hamano On Wed, Sep 26, 2018 at 05:24:14PM +0200, Duy Nguyen wrote: > On Wed, Sep 26, 2018 at 6:46 AM Kaartic Sivaraam > <kaartic.sivaraam@gmail.com> wrote: > > This is the most interesting part of the issue. I **did not** run > >'git fetch ...' in between those cat commands. I was surprised by > >how the contents of FETCH_HEAD are changing without me spawning any > >git processes that might change it. Am I missing something here? As > >far as i could remember, there wasn't any IDE running that might > >automatically spawn git commands especially in that work > >tree. Weird. Maybe something like this could help track down that rogue "git fetch" process (it's definitely _some_ process writing to the wrong file; or some file synchronization thingy is going on). You can log more of course, but this is where FETCH_HEAD is updated. -- 8< -- diff --git a/builtin/fetch.c b/builtin/fetch.c index 0696abfc2a..0dfb580e92 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -786,6 +786,13 @@ static int store_updated_refs(const char *raw_url, const char *remote_name, if (!fp) return error_errno(_("cannot open %s"), filename); + { + struct strbuf sb = STRBUF_INIT; + strbuf_addf(&sb, "( date; ls -l /proc/%d/cwd ) >>%s.log", getpid(), filename); + system(sb.buf); + strbuf_release(&sb); + } + if (raw_url) url = transport_anonymize_url(raw_url); else -- 8< -- -- Duy ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-09-26 16:09 ` Duy Nguyen @ 2018-09-26 17:05 ` Junio C Hamano 2018-10-02 18:43 ` Kaartic Sivaraam 0 siblings, 1 reply; 12+ messages in thread From: Junio C Hamano @ 2018-09-26 17:05 UTC (permalink / raw) To: Duy Nguyen; +Cc: Kaartic Sivaraam, Git Mailing List Duy Nguyen <pclouds@gmail.com> writes: > On Wed, Sep 26, 2018 at 05:24:14PM +0200, Duy Nguyen wrote: >> On Wed, Sep 26, 2018 at 6:46 AM Kaartic Sivaraam >> <kaartic.sivaraam@gmail.com> wrote: >> > This is the most interesting part of the issue. I **did not** run >> >'git fetch ...' in between those cat commands. I was surprised by >> >how the contents of FETCH_HEAD are changing without me spawning any >> >git processes that might change it. Am I missing something here? As >> >far as i could remember, there wasn't any IDE running that might >> >automatically spawn git commands especially in that work >> >tree. Weird. > > Maybe something like this could help track down that rogue "git fetch" > process (it's definitely _some_ process writing to the wrong file; or > some file synchronization thingy is going on). You can log more of > course, but this is where FETCH_HEAD is updated. Well, a background-ish thing could be some vendor-provided copy of Git that has nothing to do with what Kaartic would be compiling with this patch X-<. > -- 8< -- > diff --git a/builtin/fetch.c b/builtin/fetch.c > index 0696abfc2a..0dfb580e92 100644 > --- a/builtin/fetch.c > +++ b/builtin/fetch.c > @@ -786,6 +786,13 @@ static int store_updated_refs(const char *raw_url, const char *remote_name, > if (!fp) > return error_errno(_("cannot open %s"), filename); > > + { > + struct strbuf sb = STRBUF_INIT; > + strbuf_addf(&sb, "( date; ls -l /proc/%d/cwd ) >>%s.log", getpid(), filename); > + system(sb.buf); > + strbuf_release(&sb); > + } > + > if (raw_url) > url = transport_anonymize_url(raw_url); > else > -- 8< -- > > -- > Duy ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-09-26 17:05 ` Junio C Hamano @ 2018-10-02 18:43 ` Kaartic Sivaraam 2018-10-04 6:54 ` Kaartic Sivaraam 0 siblings, 1 reply; 12+ messages in thread From: Kaartic Sivaraam @ 2018-10-02 18:43 UTC (permalink / raw) To: Junio C Hamano, Duy Nguyen; +Cc: Git Mailing List Hi, Sorry for the delay. Got a little busy over the weekend. I seem to have found the reason behind the issue in the mean time :-) On Wed, 2018-09-26 at 10:05 -0700, Junio C Hamano wrote: > Duy Nguyen <pclouds@gmail.com> writes: > > > On Wed, Sep 26, 2018 at 05:24:14PM +0200, Duy Nguyen wrote: > > > On Wed, Sep 26, 2018 at 6:46 AM Kaartic Sivaraam > > > <kaartic.sivaraam@gmail.com> wrote: > > > > This is the most interesting part of the issue. I **did not** run > > > > 'git fetch ...' in between those cat commands. I was surprised by > > > > how the contents of FETCH_HEAD are changing without me spawning any > > > > git processes that might change it. Am I missing something here? As > > > > far as i could remember, there wasn't any IDE running that might > > > > automatically spawn git commands especially in that work > > > > tree. Weird. > > > > Maybe something like this could help track down that rogue "git fetch" > > process (it's definitely _some_ process writing to the wrong file; or > > some file synchronization thingy is going on). You can log more of > > course, but this is where FETCH_HEAD is updated. > Thanks for the patch! It really helped me identify the issue. The actual culprit here doesn't seem to be Git itself. It was the "git- prompt" bash plug-in[1] I was using. It seems to be spawning "git fetch" for every command I type on shell. That answers why the FETCH_HEAD was being updated even though I wasn't explicitly running it. The git bash plug-in seems to be fetching changes for *all* the upstream branches. That answers why there FETCH_HEAD was populated with info about all the branches when I explicitly requested for the next branch. I've also verified that `git fetch origin next` works as intended (FETCH_HEAD has info only about orgin/next) when I turn-off the plug-in which confirms that it's the culprit. A cursory search found me a related issue[2] but I'm not sure if it's the exact same one. I could identify the culprit only with the help of Duy's patch. Thanks Duy! Sorry for not realising this earlier. I almost forgot I'm using it as I've been accustomed to it a lot. > Well, a background-ish thing could be some vendor-provided copy of > Git that has nothing to do with what Kaartic would be compiling with > this patch X-<. Fortunately, it wasn't the case here as the plug-in was using my manually-built version of Git :-) Thanks for the help! Tag-line: Sometimes tools become part of our workflow so much that we really don't realise their presence. It's an indication of a good tool but we should be aware of suspecting them when an issue arises! Something which I should have done to realise the issue ealier x-< References: [1]: https://github.com/magicmonty/bash-git-prompt [2]: https://github.com/magicmonty/bash-git-prompt/issues/125 Thanks, Sivaraam ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-10-02 18:43 ` Kaartic Sivaraam @ 2018-10-04 6:54 ` Kaartic Sivaraam 2018-10-04 7:00 ` Duy Nguyen 0 siblings, 1 reply; 12+ messages in thread From: Kaartic Sivaraam @ 2018-10-04 6:54 UTC (permalink / raw) To: Junio C Hamano, Duy Nguyen; +Cc: Git Mailing List On 3 October 2018 00:13:06 GMT+05:30, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote: >Hi, > >Sorry for the delay. Got a little busy over the weekend. I seem to have >found the reason behind the issue in the mean time :-) > Oops, I forgot to mention there's more comments inline! BTW, is there an issue if .git/HEAD and .git/index are owned by root? The owners seem to have changed since I created the worktree possibly due to the cron job. Just wondering if it might cause some issues. >On Wed, 2018-09-26 at 10:05 -0700, Junio C Hamano wrote: >> Duy Nguyen <pclouds@gmail.com> writes: >> >> > On Wed, Sep 26, 2018 at 05:24:14PM +0200, Duy Nguyen wrote: >> > > On Wed, Sep 26, 2018 at 6:46 AM Kaartic Sivaraam >> > > <kaartic.sivaraam@gmail.com> wrote: >> > > > This is the most interesting part of the issue. I **did not** >run >> > > > 'git fetch ...' in between those cat commands. I was surprised >by >> > > > how the contents of FETCH_HEAD are changing without me spawning >any >> > > > git processes that might change it. Am I missing something >here? As >> > > > far as i could remember, there wasn't any IDE running that >might >> > > > automatically spawn git commands especially in that work >> > > > tree. Weird. >> > >> > Maybe something like this could help track down that rogue "git >fetch" >> > process (it's definitely _some_ process writing to the wrong file; >or >> > some file synchronization thingy is going on). You can log more of >> > course, but this is where FETCH_HEAD is updated. >> > >Thanks for the patch! It really helped me identify the issue. > >The actual culprit here doesn't seem to be Git itself. It was the "git- >prompt" bash plug-in[1] I was using. It seems to be spawning "git >fetch" for every command I type on shell. That answers why the >FETCH_HEAD was being updated even though I wasn't explicitly running >it. The git bash plug-in seems to be fetching changes for *all* the >upstream branches. That answers why there FETCH_HEAD was populated with >info about all the branches when I explicitly requested for the next >branch. I've also verified that `git fetch origin next` works as >intended (FETCH_HEAD has info only about orgin/next) when I turn-off >the plug-in which confirms that it's the culprit. A cursory search >found me a related issue[2] but I'm not sure if it's the exact same >one. > >I could identify the culprit only with the help of Duy's patch. Thanks >Duy! Sorry for not realising this earlier. I almost forgot I'm using it >as I've been accustomed to it a lot. > > >> Well, a background-ish thing could be some vendor-provided copy of >> Git that has nothing to do with what Kaartic would be compiling with >> this patch X-<. > >Fortunately, it wasn't the case here as the plug-in was using my >manually-built version of Git :-) > >Thanks for the help! > >Tag-line: Sometimes tools become part of our workflow so much that we >really don't realise their presence. It's an indication of a good tool >but we should be aware of suspecting them when an issue arises! >Something which I should have done to realise the issue ealier x-< > > >References: >[1]: https://github.com/magicmonty/bash-git-prompt >[2]: https://github.com/magicmonty/bash-git-prompt/issues/125 > >Thanks, >Sivaraam -- Sivaraam Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: git fetch <remote> <branch> behaves weirdely when run in a worktree 2018-10-04 6:54 ` Kaartic Sivaraam @ 2018-10-04 7:00 ` Duy Nguyen 0 siblings, 0 replies; 12+ messages in thread From: Duy Nguyen @ 2018-10-04 7:00 UTC (permalink / raw) To: Kaartic Sivaraam; +Cc: Junio C Hamano, Git Mailing List On Thu, Oct 4, 2018 at 8:55 AM Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote: > > > > On 3 October 2018 00:13:06 GMT+05:30, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote: > >Hi, > > > >Sorry for the delay. Got a little busy over the weekend. I seem to have > >found the reason behind the issue in the mean time :-) > > > > Oops, I forgot to mention there's more comments inline! > > BTW, is there an issue if .git/HEAD and .git/index are owned by root? The owners seem to have changed since I created the worktree possibly due to the cron job. Just wondering if it might cause some issues. If the files are still readable by normal user and $GIT_DIR has permission to delete/rename them, then I think everything still works. -- Duy ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-10-04 7:01 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-09-23 20:09 git fetch <remote> <branch> behaves weirdely when run in a worktree Kaartic Sivaraam 2018-09-24 15:17 ` Duy Nguyen 2018-09-25 18:44 ` Kaartic Sivaraam 2018-09-25 21:40 ` Junio C Hamano 2018-09-26 3:37 ` Kaartic Sivaraam 2018-09-26 4:46 ` Kaartic Sivaraam 2018-09-26 15:24 ` Duy Nguyen 2018-09-26 16:09 ` Duy Nguyen 2018-09-26 17:05 ` Junio C Hamano 2018-10-02 18:43 ` Kaartic Sivaraam 2018-10-04 6:54 ` Kaartic Sivaraam 2018-10-04 7:00 ` Duy Nguyen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).