{"thread":{"id":"62336","subject":"git rebase exec make -C in worktree confuses repo root dir","startedAt":"2024-10-14T20:46:58Z","lastAt":"2024-11-05T15:24:45Z","messageCount":11,"participants":["David Moberg","Taylor Blau","Eric Sunshine","Phillip Wood","Elijah Newren","phillip.wood123@gmail.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"505057","messageId":"CAL2+Miudq0UXAb=R24v+ftZVkHy2We1CFsFAt__tCYMWtCfOow@mail.gmail.com","threadId":"62336","inReplyTo":null,"subject":"git rebase exec make -C in worktree confuses repo root dir","fromName":"David Moberg","fromEmail":"kaddkaka@gmail.com","sentAt":"2024-10-14T20:46:45Z","receivedAt":"2024-10-14T20:46:58Z","isPatch":false,"sender":{"key":"kaddkaka@gmail.com","avatar":null},"body":"Hi, I tried to minimize this but I haven't been able to come to a much\nsmaller example.\n\n/David \"kaddkaka\" Moberg\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\nWhen doing `git rebase --exec` in a \"secondary\" worktree, it seems\nthat there is confusion about\nwhere the repo root dir is. This sequence of commands can be run to reproduce:\n\n  mktemp -d /tmp/git_bugreport_rebase_exec_worktree_root.XXXXXX\n  cd /tmp/git_bugreport_rebase_exec_worktree_root.*\n  mkdir repo\n  cd repo/\n  mkdir dir\n  echo -e 'lint:' > dir/Makefile\n  echo -e '\\tgit rev-parse --show-toplevel' >> dir/Makefile\n  echo -e '\\tgit grep \"banana\" -- \"$$BANANA\"' >> dir/Makefile\n  git init\n  git add dir\n  git commit -m\"Intial commit\"\n  git worktree add ../repo2\n  cd ../repo2/\n  BANANA=$PWD GIT_EDITOR='sed -i \"1s/noop/exec make -C dir\\/ lint/\"'\ngit rebase -i HEAD\n\nWhat did you expect to happen? (Expected behavior)\n\n1. This command should return the worktree toplevel, not a subdirectory\n  $ git rev-parse --show-toplevel\n  /tmp/tmp.DUUAVQCIKe/repo2\n\n2. And the git grep command should return the match from dir/Makefile,\nnot Fatal Error\n  $ git grep banana\n  Makefile:       git grep \"banana\" -- \"$$BANANA\"\n\nWhat happened instead? (Actual behavior)\n\n1. --show-toplevel reports a subdirectory instead of toplevel:\n  $ git rev-parse --show-toplevel\n  /tmp/tmp.DUUAVQCIKe/repo2/dir\n2. git grep complains that the pathspec is outside the repository with\nfatal error:\n  $ git grep \"banana\" -- \"$BANANA\"\n  fatal: /tmp/tmp.DUUAVQCIKe/repo2: '/tmp/tmp.DUUAVQCIKe/repo2' is\noutside repository at '/tmp/tmp.DUUAVQCIKe/repo2/dir'\n  make: *** [Makefile:3: lint] Error 128\n  make: Leaving directory '/tmp/tmp.DUUAVQCIKe/repo2/dir'\n  warning: execution failed: make -C dir/ lint\n\nWhat's different between what you expected and what actually happened?\n\nSee above.\n\n[System Info]\ngit version:\ngit version 2.43.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug\n30 12:02:04 UTC 2024 x86_64\ncompiler info: gnuc: 13.2\nlibc info: glibc: 2.39\n$SHELL (typically, interactive shell): /usr/bin/bash\n\n\n[Enabled Hooks]\n"},{"id":"505067","messageId":"Zw2K5xJAOGWitfXr@nand.local","threadId":"62336","inReplyTo":"CAL2+Miudq0UXAb=R24v+ftZVkHy2We1CFsFAt__tCYMWtCfOow@mail.gmail.com","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-10-14T21:19:35Z","receivedAt":"2024-10-14T21:19:38Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, Oct 14, 2024 at 10:46:45PM +0200, David Moberg wrote:\n> What did you expect to happen? (Expected behavior)\n>\n> 1. This command should return the worktree toplevel, not a subdirectory\n>   $ git rev-parse --show-toplevel\n>   /tmp/tmp.DUUAVQCIKe/repo2\n>\n> 2. And the git grep command should return the match from dir/Makefile,\n> not Fatal Error\n>   $ git grep banana\n>   Makefile:       git grep \"banana\" -- \"$$BANANA\"\n\nI am not sure if this is expected behavior or not, but it feels\nunintentional to me. Perhaps I am missing something funky in your\nexample that is causing it to behave this way.\n\nDoes this bisect to anything interesting, or has it always behaved this\nway?\n\nThanks,\nTaylor\n"},{"id":"505071","messageId":"CAL2+MiuG4FQdV3c4tGqcRgV+JWxAfvbo91vdGsnFHwDT0y_VRw@mail.gmail.com","threadId":"62336","inReplyTo":"Zw2K5xJAOGWitfXr@nand.local","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"David Moberg","fromEmail":"kaddkaka@gmail.com","sentAt":"2024-10-14T21:34:28Z","receivedAt":"2024-10-14T21:34:41Z","isPatch":false,"sender":{"key":"kaddkaka@gmail.com","avatar":null},"body":"I am not sure if this has worked previously. Where/how far back should\nI look? Is 2 samples from 6 months and 1 year prior reasonable and\nenough?\n\nI'm not sure if I understand you, What is the behavior you expect?\nAre you able to reproduce the behavior?\n\n/David\n\nDen mån 14 okt. 2024 kl 23:19 skrev Taylor Blau <me@ttaylorr.com>:\n>\n> On Mon, Oct 14, 2024 at 10:46:45PM +0200, David Moberg wrote:\n> > What did you expect to happen? (Expected behavior)\n> >\n> > 1. This command should return the worktree toplevel, not a subdirectory\n> >   $ git rev-parse --show-toplevel\n> >   /tmp/tmp.DUUAVQCIKe/repo2\n> >\n> > 2. And the git grep command should return the match from dir/Makefile,\n> > not Fatal Error\n> >   $ git grep banana\n> >   Makefile:       git grep \"banana\" -- \"$$BANANA\"\n>\n> I am not sure if this is expected behavior or not, but it feels\n> unintentional to me. Perhaps I am missing something funky in your\n> example that is causing it to behave this way.\n>\n> Does this bisect to anything interesting, or has it always behaved this\n> way?\n>\n> Thanks,\n> Taylor\n"},{"id":"505120","messageId":"CAPig+cQZoO8tMZ1Gip-at8-9n_tk4axctkX=WbaO1==JRru39A@mail.gmail.com","threadId":"62336","inReplyTo":"Zw2K5xJAOGWitfXr@nand.local","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-10-15T07:11:18Z","receivedAt":"2024-10-15T07:11:41Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Oct 14, 2024 at 5:19 PM Taylor Blau <me@ttaylorr.com> wrote:\n> On Mon, Oct 14, 2024 at 10:46:45PM +0200, David Moberg wrote:\n> > 1. This command should return the worktree toplevel, not a subdirectory\n> >   $ git rev-parse --show-toplevel\n> >   /tmp/tmp.DUUAVQCIKe/repo2\n> >\n> > 2. And the git grep command should return the match from dir/Makefile,\n> > not Fatal Error\n> >   $ git grep banana\n> >   Makefile:       git grep \"banana\" -- \"$$BANANA\"\n>\n> I am not sure if this is expected behavior or not, but it feels\n> unintentional to me. Perhaps I am missing something funky in your\n> example that is causing it to behave this way.\n\nThis looks like unintentional behavior; probably a bug. It seems to be\ntriggered by `git rebase -i` setting GIT_DIR. Here's an even simpler\nreproduction recipe:\n\n    % git init foo\n    % cd foo\n    % mkdir dir\n    % echo foo >dir/file\n    % git add dir/file\n    % git commit -m foo\n    % git worktree add ../bar\n    % cd ../bar\n    % git -C dir rev-parse --show-toplevel\n    /.../bar\n    % GIT_DIR=../../foo/.git/worktrees/bar \\\n        git -C dir rev-parse --show-toplevel\n    /.../bar/dir\n\nThe `git rev-parse --show-toplevel` invocation with GIT_DIR set is\nincorrectly returning `/.../bar/dir` rather than `/.../bar`.\n"},{"id":"505186","messageId":"CAL2+MivOu=_HYg+2KoMKMUtz+=q2jv-K9u9Zxrhe3OuHLCmwFA@mail.gmail.com","threadId":"62336","inReplyTo":"CAPig+cQZoO8tMZ1Gip-at8-9n_tk4axctkX=WbaO1==JRru39A@mail.gmail.com","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"David Moberg","fromEmail":"kaddkaka@gmail.com","sentAt":"2024-10-15T18:55:22Z","receivedAt":"2024-10-15T18:55:35Z","isPatch":false,"sender":{"key":"kaddkaka@gmail.com","avatar":null},"body":"Thanks, that is indeed a much smaller example and it seems to exhibit\nthe same issue. Can we figure out how to fix it?\n\nDen tis 15 okt. 2024 kl 09:11 skrev Eric Sunshine <sunshine@sunshineco.com>:\n>\n> On Mon, Oct 14, 2024 at 5:19 PM Taylor Blau <me@ttaylorr.com> wrote:\n> > On Mon, Oct 14, 2024 at 10:46:45PM +0200, David Moberg wrote:\n> > > 1. This command should return the worktree toplevel, not a subdirectory\n> > >   $ git rev-parse --show-toplevel\n> > >   /tmp/tmp.DUUAVQCIKe/repo2\n> > >\n> > > 2. And the git grep command should return the match from dir/Makefile,\n> > > not Fatal Error\n> > >   $ git grep banana\n> > >   Makefile:       git grep \"banana\" -- \"$$BANANA\"\n> >\n> > I am not sure if this is expected behavior or not, but it feels\n> > unintentional to me. Perhaps I am missing something funky in your\n> > example that is causing it to behave this way.\n>\n> This looks like unintentional behavior; probably a bug. It seems to be\n> triggered by `git rebase -i` setting GIT_DIR. Here's an even simpler\n> reproduction recipe:\n>\n>     % git init foo\n>     % cd foo\n>     % mkdir dir\n>     % echo foo >dir/file\n>     % git add dir/file\n>     % git commit -m foo\n>     % git worktree add ../bar\n>     % cd ../bar\n>     % git -C dir rev-parse --show-toplevel\n>     /.../bar\n>     % GIT_DIR=../../foo/.git/worktrees/bar \\\n>         git -C dir rev-parse --show-toplevel\n>     /.../bar/dir\n>\n> The `git rev-parse --show-toplevel` invocation with GIT_DIR set is\n> incorrectly returning `/.../bar/dir` rather than `/.../bar`.\n"},{"id":"505206","messageId":"CAPig+cQ6=HDD447xTHQ84hmsF3SMbC5nH_PXf3rZWvTWmp18ug@mail.gmail.com","threadId":"62336","inReplyTo":"CAL2+MivOu=_HYg+2KoMKMUtz+=q2jv-K9u9Zxrhe3OuHLCmwFA@mail.gmail.com","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-10-15T20:01:21Z","receivedAt":"2024-10-15T20:01:33Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Oct 15, 2024 at 2:55 PM David Moberg <kaddkaka@gmail.com> wrote:\n> Den tis 15 okt. 2024 kl 09:11 skrev Eric Sunshine <sunshine@sunshineco.com>:\n> > This looks like unintentional behavior; probably a bug. It seems to be\n> > triggered by `git rebase -i` setting GIT_DIR. Here's an even simpler\n> > reproduction recipe:\n> >\n> >     % git init foo\n> >     % cd foo\n> >     % mkdir dir\n> >     % echo foo >dir/file\n> >     % git add dir/file\n> >     % git commit -m foo\n> >     % git worktree add ../bar\n> >     % cd ../bar\n> >     % git -C dir rev-parse --show-toplevel\n> >     /.../bar\n> >     % GIT_DIR=../../foo/.git/worktrees/bar \\\n> >         git -C dir rev-parse --show-toplevel\n> >     /.../bar/dir\n> >\n> > The `git rev-parse --show-toplevel` invocation with GIT_DIR set is\n> > incorrectly returning `/.../bar/dir` rather than `/.../bar`.\n>\n> Thanks, that is indeed a much smaller example and it seems to exhibit\n> the same issue. Can we figure out how to fix it?\n\nSomeone is going to have to dig into the code, but my Git time is very\nlimited right now, so perhaps someone else can do the digging.\n\nIf you want an immediate workaround for the problem for your specific\nuse-case, you can probably unset GIT_DIR in your `exec` instruction.\n\n(By the way, please avoid top-posting when you reply on this list;\ninstead, post inline as I did here.)\n"},{"id":"505259","messageId":"1dc91aa7-04da-4023-bbd5-5b12539477ba@gmail.com","threadId":"62336","inReplyTo":"CAPig+cQ6=HDD447xTHQ84hmsF3SMbC5nH_PXf3rZWvTWmp18ug@mail.gmail.com","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-10-16T09:15:49Z","receivedAt":"2024-10-16T09:15:52Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 15/10/2024 21:01, Eric Sunshine wrote:\n> On Tue, Oct 15, 2024 at 2:55 PM David Moberg <kaddkaka@gmail.com> wrote:\n>> Den tis 15 okt. 2024 kl 09:11 skrev Eric Sunshine <sunshine@sunshineco.com>:\n>>> This looks like unintentional behavior; probably a bug. It seems to be\n>>> triggered by `git rebase -i` setting GIT_DIR. Here's an even simpler\n>>> reproduction recipe:\n>>>\n>>>      % git init foo\n>>>      % cd foo\n>>>      % mkdir dir\n>>>      % echo foo >dir/file\n>>>      % git add dir/file\n>>>      % git commit -m foo\n>>>      % git worktree add ../bar\n>>>      % cd ../bar\n>>>      % git -C dir rev-parse --show-toplevel\n>>>      /.../bar\n>>>      % GIT_DIR=../../foo/.git/worktrees/bar \\\n>>>          git -C dir rev-parse --show-toplevel\n>>>      /.../bar/dir\n>>>\n>>> The `git rev-parse --show-toplevel` invocation with GIT_DIR set is\n>>> incorrectly returning `/.../bar/dir` rather than `/.../bar`.\n>>\n>> Thanks, that is indeed a much smaller example and it seems to exhibit\n>> the same issue. Can we figure out how to fix it?\n> \n> Someone is going to have to dig into the code, but my Git time is very\n> limited right now, so perhaps someone else can do the digging.\n\nI'm about to go off the list until the 29th so I wont be working on it \nsoon either but I think the problem is that git sets $GIT_DIR when it is \nrun from a linked worktree. I've reproduced the commit message from \nff5b7913f0a (sequencer, stash: fix running from worktree subdir, \n2022-01-26) below which I think explains the problem we're seeing here. \nUnfortunately the approach of setting $GIT_WORK_TREE used in that commit \nwon't work for exec commands as they may be run in a different worktree. \nNaively I feel that if setup_git_directory() has found \".git\" then any \ngit subprocesses run in the worktree should also be able to find \".git\" \nand so it should not be setting $GIT_DIR but there maybe there is some \nsubtlety I'm missing\n\n\n     commit ff5b7913f0af62c26682b0376d0aa2d7f5d74b2e\n     Author: Elijah Newren <newren@gmail.com>\n     Date:   Wed Jan 26 01:43:45 2022 +0000\n\n     sequencer, stash: fix running from worktree subdir\n\n     In commits bc3ae46b42 (\"rebase: do not attempt to remove\n     startup_info->original_cwd\", 2021-12-09) and 0fce211ccc (\"stash: do\n     not attempt to remove startup_info->original_cwd\", 2021-12-09), we\n     wanted to allow the subprocess to know which directory the parent\n     process was running from, so that the subprocess could protect it.\n     However...\n\n     When run from a non-main worktree, setup_git_directory() will note\n     that the discovered git directory\n     (/PATH/TO/.git/worktree/non-main-worktree) does not match\n     DEFAULT_GIT_DIR_ENVIRONMENT (see setup_discovered_git_dir()), and\n     decide to set GIT_DIR in the environment.  This matters because...\n\n     Whenever git is run with the GIT_DIR environment variable set, and\n     GIT_WORK_TREE not set, it presumes that '.' is the working tree.\n     So...\n\n     This combination results in the subcommand being very confused about\n     the working tree.  Fix it by also setting the GIT_WORK_TREE\n     environment variable along with setting cmd.dir.\n\n     A possibly more involved fix we could consider for later would be to\n     make setup.c set GIT_WORK_TREE whenever (a) it discovers both the\n     git directory and the working tree and (b) it decides to set GIT_DIR\n     in the environment.  I did not attempt that here as such would be\n     too big of a change for a 2.35.1 release.\n\n     Test-case-by: Glen Choo <chooglen@google.com>\n     Signed-off-by: Elijah Newren <newren@gmail.com>\n     Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\n> If you want an immediate workaround for the problem for your specific\n> use-case, you can probably unset GIT_DIR in your `exec` instruction.\n\nIndeed I think that should work in this case. Unfortunately we cannot do \nthat unconditionally when running exec commands as the user may have set \nGIT_DIR when running \"git rebase\"\n\nBest Wishes\n\nPhillip\n\n> (By the way, please avoid top-posting when you reply on this list;\n> instead, post inline as I did here.)\n> \n\n"},{"id":"505297","messageId":"ZxAjz28QLwWlDVg1@nand.local","threadId":"62336","inReplyTo":"1dc91aa7-04da-4023-bbd5-5b12539477ba@gmail.com","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2024-10-16T20:36:31Z","receivedAt":"2024-10-16T20:36:35Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Oct 16, 2024 at 10:15:49AM +0100, Phillip Wood wrote:\n> On 15/10/2024 21:01, Eric Sunshine wrote:\n> > On Tue, Oct 15, 2024 at 2:55 PM David Moberg <kaddkaka@gmail.com> wrote:\n> > > Den tis 15 okt. 2024 kl 09:11 skrev Eric Sunshine <sunshine@sunshineco.com>:\n> > > > This looks like unintentional behavior; probably a bug. It seems to be\n> > > > triggered by `git rebase -i` setting GIT_DIR. Here's an even simpler\n> > > > reproduction recipe:\n> > > >\n> > > >      % git init foo\n> > > >      % cd foo\n> > > >      % mkdir dir\n> > > >      % echo foo >dir/file\n> > > >      % git add dir/file\n> > > >      % git commit -m foo\n> > > >      % git worktree add ../bar\n> > > >      % cd ../bar\n> > > >      % git -C dir rev-parse --show-toplevel\n> > > >      /.../bar\n> > > >      % GIT_DIR=../../foo/.git/worktrees/bar \\\n> > > >          git -C dir rev-parse --show-toplevel\n> > > >      /.../bar/dir\n> > > >\n> > > > The `git rev-parse --show-toplevel` invocation with GIT_DIR set is\n> > > > incorrectly returning `/.../bar/dir` rather than `/.../bar`.\n> > >\n> > > Thanks, that is indeed a much smaller example and it seems to exhibit\n> > > the same issue. Can we figure out how to fix it?\n> >\n> > Someone is going to have to dig into the code, but my Git time is very\n> > limited right now, so perhaps someone else can do the digging.\n>\n> I'm about to go off the list until the 29th so I wont be working on it soon\n> either but I think the problem is that git sets $GIT_DIR when it is run from\n> a linked worktree. I've reproduced the commit message from ff5b7913f0a\n> (sequencer, stash: fix running from worktree subdir, 2022-01-26) below which\n> I think explains the problem we're seeing here. Unfortunately the approach\n> of setting $GIT_WORK_TREE used in that commit won't work for exec commands\n> as they may be run in a different worktree. Naively I feel that if\n> setup_git_directory() has found \".git\" then any git subprocesses run in the\n> worktree should also be able to find \".git\" and so it should not be setting\n> $GIT_DIR but there maybe there is some subtlety I'm missing\n\nLet's see if that commit's author Elijah (CC'd) has any other thoughts.\n\nThanks,\nTaylor\n"},{"id":"505312","messageId":"CAPig+cQmGXxDshTovdAYaZn5UMr3nvXHyH0q2HvAbaT_fhhiLQ@mail.gmail.com","threadId":"62336","inReplyTo":"1dc91aa7-04da-4023-bbd5-5b12539477ba@gmail.com","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-10-16T21:12:59Z","receivedAt":"2024-10-16T21:13:11Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Oct 16, 2024 at 5:15 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n> On 15/10/2024 21:01, Eric Sunshine wrote:\n> >> Den tis 15 okt. 2024 kl 09:11 skrev Eric Sunshine <sunshine@sunshineco.com>:\n> >>> This looks like unintentional behavior; probably a bug. It seems to be\n> >>> triggered by `git rebase -i` setting GIT_DIR. [...]\n> >>>      % git -C dir rev-parse --show-toplevel\n> >>>      /.../bar\n> >>>      % GIT_DIR=../../foo/.git/worktrees/bar \\\n> >>>          git -C dir rev-parse --show-toplevel\n> >>>      /.../bar/dir\n> >>>\n> >>> The `git rev-parse --show-toplevel` invocation with GIT_DIR set is\n> >>> incorrectly returning `/.../bar/dir` rather than `/.../bar`.\n>\n> I'm about to go off the list until the 29th so I wont be working on it\n> soon either but I think the problem is that git sets $GIT_DIR when it is\n> run from a linked worktree. I've reproduced the commit message from\n> ff5b7913f0a (sequencer, stash: fix running from worktree subdir,\n> 2022-01-26) below which I think explains the problem we're seeing here.\n> Unfortunately the approach of setting $GIT_WORK_TREE used in that commit\n> won't work for exec commands as they may be run in a different worktree.\n\nMaybe. Maybe not. exec'ing a command in a worktree other than the\ncurrent worktree may be a \"don't do it if it hurts\" situation. The\nsame shortcoming you describe would crop up when exec'ing a command in\na foreign repository from the one in which `git rebase -i` is being\nrun. If we look at it that way (\"don't do it if it hurts\"), then\nperhaps a documentation update is warranted; something along the lines\n[1] which gives explains that GIT_* environment variables should be\ncleared by a Git hook if it needs to peek into a foreign repository or\nother worktree. It's not a perfectly satisfactory answer, but would at\nleast (somewhat?) allay your concern about `git rebase -i` setting\nGIT_WORK_TREE automatically.\n\n[1]: https://lore.kernel.org/git/pull.1457.git.1673171924727.gitgitgadget@gmail.com/\n"},{"id":"505397","messageId":"CABPp-BG6kYvx_EDRUfTUtcPrpnDT=FyAMDVXrQVyVJF5Rdj_tw@mail.gmail.com","threadId":"62336","inReplyTo":"ZxAjz28QLwWlDVg1@nand.local","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2024-10-17T21:16:51Z","receivedAt":"2024-10-17T21:17:03Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Oct 16, 2024 at 1:36 PM Taylor Blau <me@ttaylorr.com> wrote:\n>\n> On Wed, Oct 16, 2024 at 10:15:49AM +0100, Phillip Wood wrote:\n> > On 15/10/2024 21:01, Eric Sunshine wrote:\n> > > On Tue, Oct 15, 2024 at 2:55 PM David Moberg <kaddkaka@gmail.com> wrote:\n> > > > Den tis 15 okt. 2024 kl 09:11 skrev Eric Sunshine <sunshine@sunshineco.com>:\n> > > > > This looks like unintentional behavior; probably a bug. It seems to be\n> > > > > triggered by `git rebase -i` setting GIT_DIR. Here's an even simpler\n> > > > > reproduction recipe:\n> > > > >\n> > > > >      % git init foo\n> > > > >      % cd foo\n> > > > >      % mkdir dir\n> > > > >      % echo foo >dir/file\n> > > > >      % git add dir/file\n> > > > >      % git commit -m foo\n> > > > >      % git worktree add ../bar\n> > > > >      % cd ../bar\n> > > > >      % git -C dir rev-parse --show-toplevel\n> > > > >      /.../bar\n> > > > >      % GIT_DIR=../../foo/.git/worktrees/bar \\\n> > > > >          git -C dir rev-parse --show-toplevel\n> > > > >      /.../bar/dir\n> > > > >\n> > > > > The `git rev-parse --show-toplevel` invocation with GIT_DIR set is\n> > > > > incorrectly returning `/.../bar/dir` rather than `/.../bar`.\n> > > >\n> > > > Thanks, that is indeed a much smaller example and it seems to exhibit\n> > > > the same issue. Can we figure out how to fix it?\n> > >\n> > > Someone is going to have to dig into the code, but my Git time is very\n> > > limited right now, so perhaps someone else can do the digging.\n> >\n> > I'm about to go off the list until the 29th so I wont be working on it soon\n> > either but I think the problem is that git sets $GIT_DIR when it is run from\n> > a linked worktree. I've reproduced the commit message from ff5b7913f0a\n> > (sequencer, stash: fix running from worktree subdir, 2022-01-26) below which\n> > I think explains the problem we're seeing here. Unfortunately the approach\n> > of setting $GIT_WORK_TREE used in that commit won't work for exec commands\n> > as they may be run in a different worktree. Naively I feel that if\n> > setup_git_directory() has found \".git\" then any git subprocesses run in the\n> > worktree should also be able to find \".git\" and so it should not be setting\n> > $GIT_DIR but there maybe there is some subtlety I'm missing\n>\n> Let's see if that commit's author Elijah (CC'd) has any other thoughts.\n>\n> Thanks,\n> Taylor\n\nMy commit merely pointed out that long before that commit came along,\nif GIT_DIR is set but GIT_WORK_TREE is not, then the working tree is\nassumed to be \".\".  As such, a command like the above where\n`--show-toplevel` is run with just GIT_DIR set (to anything) will\nmerely expand \".\" and show you that path.\n\nIf you are going to be having subprocesses that depend upon the git\ndirectory and the git working tree, I think there are two options:\n  * Set GIT_WORK_TREE in addition to GIT_DIR (as my patch does in certain cases)\n  * Stop setting GIT_DIR if you're not going to set GIT_WORK_TREE\n\nThe second point is a bit harder since setup.c automatically sets\nGIT_DIR for you in various cases, so if you want to go that route it\nreally means you'd have to actively unset GIT_DIR in those cases.\nBut, you'd have to be careful since you only want to unset it when\nsetup_discovered_git_dir() sets it for you, not when the user who\ninvoked your command had manually set GIT_DIR.  So, there is a little\nbit of a pickle here...\n"},{"id":"506665","messageId":"743043bf-60b7-4ed7-8cf2-4f3f972968a6@gmail.com","threadId":"62336","inReplyTo":"CAPig+cQmGXxDshTovdAYaZn5UMr3nvXHyH0q2HvAbaT_fhhiLQ@mail.gmail.com","subject":"Re: git rebase exec make -C in worktree confuses repo root dir","fromName":"","fromEmail":"phillip.wood123@gmail.com","sentAt":"2024-11-05T15:24:42Z","receivedAt":"2024-11-05T15:24:45Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 16/10/2024 22:12, Eric Sunshine wrote:\n> On Wed, Oct 16, 2024 at 5:15 AM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>> On 15/10/2024 21:01, Eric Sunshine wrote:\n>>>> Den tis 15 okt. 2024 kl 09:11 skrev Eric Sunshine <sunshine@sunshineco.com>:\n>>>>> This looks like unintentional behavior; probably a bug. It seems to be\n>>>>> triggered by `git rebase -i` setting GIT_DIR. [...]\n>>>>>       % git -C dir rev-parse --show-toplevel\n>>>>>       /.../bar\n>>>>>       % GIT_DIR=../../foo/.git/worktrees/bar \\\n>>>>>           git -C dir rev-parse --show-toplevel\n>>>>>       /.../bar/dir\n>>>>>\n>>>>> The `git rev-parse --show-toplevel` invocation with GIT_DIR set is\n>>>>> incorrectly returning `/.../bar/dir` rather than `/.../bar`.\n>>\n>> I'm about to go off the list until the 29th so I wont be working on it\n>> soon either but I think the problem is that git sets $GIT_DIR when it is\n>> run from a linked worktree. I've reproduced the commit message from\n>> ff5b7913f0a (sequencer, stash: fix running from worktree subdir,\n>> 2022-01-26) below which I think explains the problem we're seeing here.\n>> Unfortunately the approach of setting $GIT_WORK_TREE used in that commit\n>> won't work for exec commands as they may be run in a different worktree.\n> \n> Maybe. Maybe not. exec'ing a command in a worktree other than the\n> current worktree may be a \"don't do it if it hurts\" situation. The\n> same shortcoming you describe would crop up when exec'ing a command in\n> a foreign repository from the one in which `git rebase -i` is being\n> run. If we look at it that way (\"don't do it if it hurts\"), then\n> perhaps a documentation update is warranted; something along the lines\n> [1] which gives explains that GIT_* environment variables should be\n> cleared by a Git hook if it needs to peek into a foreign repository or\n> other worktree. It's not a perfectly satisfactory answer, but would at\n> least (somewhat?) allay your concern about `git rebase -i` setting\n> GIT_WORK_TREE automatically.\n\nThat's certainly the simplest way forward. Until 434e0636db1 (sequencer: \ndo not export GIT_DIR and GIT_WORK_TREE for 'exec', 2021-12-04)\nwe set both GIT_DIR and GIT_WORK_TREE when running an exec command. As \nthe message for that commit explains that behavior did not match the \nscripted rebase which was the motivation to stop doing it. Unfortunately \nthat left us in the situation where git will sometimes set GIT_DIR when \nthe user has not. Ideally I'd like to understand why we're setting \nGIT_DIR in setup_git_dir() when, at least at fist sight, it seems to be \nunnecessary. I think that would take some time so maybe we should just \ngo back to setting GIT_DIR and GIT_WORK_TREE in the sequencer when \nrunning \"exec\" commands.\n\nBest Wishes\n\nPhillip\n\n> [1]: https://lore.kernel.org/git/pull.1457.git.1673171924727.gitgitgadget@gmail.com/\n\n"}]}