* 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
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).