{"thread":{"id":"54417","subject":"[BUG?] Weird interaction between `git -C`, aliases and worktrees","startedAt":"2020-10-14T15:27:34Z","lastAt":"2020-10-16T00:23:56Z","messageCount":4,"participants":["Philippe Blain","Elijah Newren","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"407518","messageId":"020EB674-6A95-4E53-B2E7-F4EEBD6324C3@gmail.com","threadId":"54417","inReplyTo":null,"subject":"[BUG?] Weird interaction between `git -C`, aliases and worktrees","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-10-14T15:27:27Z","receivedAt":"2020-10-14T15:27:34Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hello all,\n\nUp to recently I had an alias 'st' for `git status`, i.e. `git config alias.st status`. \nThis works well in the main working tree as well as secondary worktrees (`git worktree add ...`),\nand also shows paths relative to the current directory if I'm not at the root of the repo, \njust like `git status`.\n\nNow I wanted to change my alias so that it ran `git status` and then an additional command, i.e.\n`git config alias.st '!git status && date'` (for demonstration purposes).\nThis works correctly in the main worktree and secondary worktrees, but since aliases\nrun from the root of the repo, the paths in the output of 'git st' are not relative\nto the current directory.\n\nSo my next attempt was `git config alias.st '!git -C \"${GIT_PREFIX}\" status && date'`,\nso that paths would be relative in the output. However, this works in the main worktree\nbut fails badly in the secondary worktree:\n\n```\nrm -rf test &&\nrm -rf test2 &&\ngit init test && \ncd test &&\nmkdir folder &&\ndate>>folder/file &&\ngit add folder/file &&\ngit ci -m \"commit\" &&\ngit config alias.st '!git -C \"${GIT_PREFIX}\" status && date' &&\ndate >>folder/file &&\necho '=== `git st` in main worktree at root ===' &&\ngit st &&\ncd folder && \necho '=== `git st` in main worktree in folder ===' &&\ngit st &&\ngit worktree add ../test2 &&\ncd ../test2 &&\ndate >>folder/file &&\necho '=== `git st` in secondary worktree at root ===' &&\ngit st && \ncd folder &&\necho '=== `git st` in secondary worktree in folder ===' &&\ngit st\n```\n\nThe last commands ouputs: \n\n```\n=== `git st` in secondary worktree in folder ===\nOn branch test2\nChanges not staged for commit:\n (use \"git add/rm ...\" to update what will be committed)\n (use \"git restore ...\" to discard changes in working directory)\n\tdeleted: folder/file\n\nUntracked files:\n (use \"git add ...\" to include in what will be committed)\n\tfile\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n```\n\nSo something is wrong in the automatic worktree path detection...\nIf I replace the alias with \n\n git config alias.st '!git -C \"${GIT_PREFIX}\" --work-tree=$PWD status && date' \n\nthen it works correctly, but I have a feeling this should not be necessary...\n\nI've CC-ed Eric (because of his work on `git worktree`) and Elijah (because\nI remember he worked on `dir.c` so maybe this is related to that code, but I'm\nnot sure).\n\nCheers,\nPhilippe\n\n"},{"id":"407560","messageId":"CABPp-BF2Stb_UfNEqYOBPjvm09oO8=ST685kZ0+U2PtPRz5_mg@mail.gmail.com","threadId":"54417","inReplyTo":"020EB674-6A95-4E53-B2E7-F4EEBD6324C3@gmail.com","subject":"Re: [BUG?] Weird interaction between `git -C`, aliases and worktrees","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-10-14T22:02:42Z","receivedAt":"2020-10-15T01:40:00Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Oct 14, 2020 at 8:27 AM Philippe Blain\n wrote:\n>\n> Hello all,\n>\n> Up to recently I had an alias 'st' for `git status`, i.e. `git config alias.st status`.\n> This works well in the main working tree as well as secondary worktrees (`git worktree add ...`),\n> and also shows paths relative to the current directory if I'm not at the root of the repo,\n> just like `git status`.\n>\n> Now I wanted to change my alias so that it ran `git status` and then an additional command, i.e.\n> `git config alias.st '!git status && date'` (for demonstration purposes).\n> This works correctly in the main worktree and secondary worktrees, but since aliases\n> run from the root of the repo, the paths in the output of 'git st' are not relative\n> to the current directory.\n>\n> So my next attempt was `git config alias.st '!git -C \"${GIT_PREFIX}\" status && date'`,\n> so that paths would be relative in the output. However, this works in the main worktree\n> but fails badly in the secondary worktree:\n>\n> ```\n> rm -rf test &&\n> rm -rf test2 &&\n> git init test &&\n> cd test &&\n> mkdir folder &&\n> date>>folder/file &&\n> git add folder/file &&\n> git ci -m \"commit\" &&\n> git config alias.st '!git -C \"${GIT_PREFIX}\" status && date' &&\n> date >>folder/file &&\n> echo '=== `git st` in main worktree at root ===' &&\n> git st &&\n> cd folder &&\n> echo '=== `git st` in main worktree in folder ===' &&\n> git st &&\n> git worktree add ../test2 &&\n> cd ../test2 &&\n> date >>folder/file &&\n> echo '=== `git st` in secondary worktree at root ===' &&\n> git st &&\n> cd folder &&\n> echo '=== `git st` in secondary worktree in folder ===' &&\n> git st\n> ```\n>\n> The last commands ouputs:\n>\n> ```\n> === `git st` in secondary worktree in folder ===\n> On branch test2\n> Changes not staged for commit:\n> (use \"git add/rm ...\" to update what will be committed)\n> (use \"git restore ...\" to discard changes in working directory)\n> deleted: folder/file\n>\n> Untracked files:\n> (use \"git add ...\" to include in what will be committed)\n> file\n>\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> ```\n>\n> So something is wrong in the automatic worktree path detection...\n> If I replace the alias with\n>\n> git config alias.st '!git -C \"${GIT_PREFIX}\" --work-tree=$PWD status && date'\n>\n> then it works correctly, but I have a feeling this should not be necessary...\n>\n> I've CC-ed Eric (because of his work on `git worktree`) and Elijah (because\n> I remember he worked on `dir.c` so maybe this is related to that code, but I'm\n> not sure).\n>\n> Cheers,\n> Philippe\n\nI don't think there's anything dir.c-specific here (thank\ngoodness...). I extended your aliases slightly to echo the command\nthey would run (so I could see the value of $GIT_PREFIX) as well as to\nprint all the GIT_* environment variables, and found that GIT_DIR was\nset as well as GIT_PREFIX, so you can duplicate the funny results with\n\nGIT_DIR=$WHEREVER git -C folder status\n\nor even\n\ngit --git-dir=$WHEREVER -C folder status\n\nIn fact, you don't need any special worktrees setup; using these\ncommands will trigger the funny status output. Looking at the\ndocumentation for core.worktree, I see\n\n\"If --git-dir or GIT_DIR is specified but none of --work-tree,\nGIT_WORK_TREE and core.worktree is specified, the current working\ndirectory is regarded as the top level of your working tree.\"\n\nand indeed, I find that if I run from the toplevel:\n\ngit --work-tree=folder/ status\n\nthen I see the same output that you are complaining about. So, it\nseems that \"the current working directory is regarded as the top level\nof your working tree\" is implemented to take effect AFTER the \"-C\nfolder\" first changes the current working directory.\n\nI haven't tracked down where in the code this happens, but I suspect\nthat this is what is happening and is the culprit behind the behavior\nyou are seeing. If I am right, it doesn't answer whether this is a\nbug, of course -- it could be that this ordering is intentional and\ndesired, or it could be that this ordering is not wanted. Anyway,\ndoes this help you track it down?\n"},{"id":"407576","messageId":"88D2A179-806F-4321-828A-359692E646B1@gmail.com","threadId":"54417","inReplyTo":"CABPp-BF2Stb_UfNEqYOBPjvm09oO8=ST685kZ0+U2PtPRz5_mg@mail.gmail.com","subject":"Re: [BUG?] Weird interaction between `git -C`, aliases and worktrees","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-10-14T22:35:39Z","receivedAt":"2020-10-15T02:14:43Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Elijah,\n\n> Le 14 oct. 2020 à 18:02, Elijah Newren a écrit :\n> \n> On Wed, Oct 14, 2020 at 8:27 AM Philippe Blain\n> wrote:\n>> \n>> Hello all,\n>> \n>> Up to recently I had an alias 'st' for `git status`, i.e. `git config alias.st status`.\n>> This works well in the main working tree as well as secondary worktrees (`git worktree add ...`),\n>> and also shows paths relative to the current directory if I'm not at the root of the repo,\n>> just like `git status`.\n>> \n>> Now I wanted to change my alias so that it ran `git status` and then an additional command, i.e.\n>> `git config alias.st '!git status && date'` (for demonstration purposes).\n>> This works correctly in the main worktree and secondary worktrees, but since aliases\n>> run from the root of the repo, the paths in the output of 'git st' are not relative\n>> to the current directory.\n>> \n>> So my next attempt was `git config alias.st '!git -C \"${GIT_PREFIX}\" status && date'`,\n>> so that paths would be relative in the output. However, this works in the main worktree\n>> but fails badly in the secondary worktree:\n>> \n>> ```\n>> rm -rf test &&\n>> rm -rf test2 &&\n>> git init test &&\n>> cd test &&\n>> mkdir folder &&\n>> date>>folder/file &&\n>> git add folder/file &&\n>> git ci -m \"commit\" &&\n>> git config alias.st '!git -C \"${GIT_PREFIX}\" status && date' &&\n>> date >>folder/file &&\n>> echo '=== `git st` in main worktree at root ===' &&\n>> git st &&\n>> cd folder &&\n>> echo '=== `git st` in main worktree in folder ===' &&\n>> git st &&\n>> git worktree add ../test2 &&\n>> cd ../test2 &&\n>> date >>folder/file &&\n>> echo '=== `git st` in secondary worktree at root ===' &&\n>> git st &&\n>> cd folder &&\n>> echo '=== `git st` in secondary worktree in folder ===' &&\n>> git st\n>> ```\n>> \n>> The last commands ouputs:\n>> \n>> ```\n>> === `git st` in secondary worktree in folder ===\n>> On branch test2\n>> Changes not staged for commit:\n>> (use \"git add/rm ...\" to update what will be committed)\n>> (use \"git restore ...\" to discard changes in working directory)\n>> deleted: folder/file\n>> \n>> Untracked files:\n>> (use \"git add ...\" to include in what will be committed)\n>> file\n>> \n>> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>> ```\n>> \n>> So something is wrong in the automatic worktree path detection...\n>> If I replace the alias with\n>> \n>> git config alias.st '!git -C \"${GIT_PREFIX}\" --work-tree=$PWD status && date'\n>> \n>> then it works correctly, but I have a feeling this should not be necessary...\n>> \n>> I've CC-ed Eric (because of his work on `git worktree`) and Elijah (because\n>> I remember he worked on `dir.c` so maybe this is related to that code, but I'm\n>> not sure).\n>> \n>> Cheers,\n>> Philippe\n> \n> I don't think there's anything dir.c-specific here (thank\n> goodness...). I extended your aliases slightly to echo the command\n> they would run (so I could see the value of $GIT_PREFIX) as well as to\n> print all the GIT_* environment variables, and found that GIT_DIR was\n> set as well as GIT_PREFIX, so you can duplicate the funny results with\n> \n> GIT_DIR=$WHEREVER git -C folder status\n> \n> or even\n> \n> git --git-dir=$WHEREVER -C folder status\n> \n> In fact, you don't need any special worktrees setup; using these\n> commands will trigger the funny status output. Looking at the\n> documentation for core.worktree, I see\n> \n> \"If --git-dir or GIT_DIR is specified but none of --work-tree,\n> GIT_WORK_TREE and core.worktree is specified, the current working\n> directory is regarded as the top level of your working tree.\"\n\nYes, this is in line with git(1) [1] :\n\n\"Specifying the location of the \".git\" directory using this option (or GIT_DIR environment variable)\n turns off the repository discovery that tries to find a directory with \".git\" subdirectory\n(which is how the repository and the top-level of the working tree are discovered), \nand tells Git that you are at the top level of the working tree. \nIf you are not at the top-level directory of the working tree,\n you should tell Git where the top-level of the working tree is, \nwith the --work-tree= option (or GIT_WORK_TREE environment variable)\"\n\n> and indeed, I find that if I run from the toplevel:\n> \n> git --work-tree=folder/ status\n> \n> then I see the same output that you are complaining about. So, it\n> seems that \"the current working directory is regarded as the top level\n> of your working tree\" is implemented to take effect AFTER the \"-C\n> folder\" first changes the current working directory.\n> \n> I haven't tracked down where in the code this happens, but I suspect\n> that this is what is happening and is the culprit behind the behavior\n> you are seeing. If I am right, it doesn't answer whether this is a\n> bug, of course -- it could be that this ordering is intentional and\n> desired, or it could be that this ordering is not wanted. Anyway,\n> does this help you track it down?\n\n\nI found two threads [2] and [3] which are manifestations of similar (or the same ?) problems...\n\nMaybe git-config(1) could document which variables will \nbe set in aliases that shell out, but even that might be tricky because it\nseems the answer is \"it depends\" (according to [2])...\n\nI also found 57ea7123c8 (git.c: make sure we do not \nleak GIT_* to alias scripts, 2015-12-20), in topic 'nd/clear-gitenv-upon-use-of-alias',\nwhich tries to clear out GIT_* variables from aliases environment,\nwhich I guess is defeated by the fact that I run `git -C` in my alias...\n\nAnyway thanks for your answer.\n\n[1] https://git-scm.com/docs/git#Documentation/git.txt---git-dirltpathgt\n[2] https://lore.kernel.org/git/20200130102933.GE840531@coredump.intra.peff.net/\n[3] https://lore.kernel.org/git/20200228190218.GC1408759@coredump.intra.peff.net/\n\nPhilippe.\n\n"},{"id":"407692","messageId":"20201016002354.GA2932796@coredump.intra.peff.net","threadId":"54417","inReplyTo":"88D2A179-806F-4321-828A-359692E646B1@gmail.com","subject":"Re: [BUG?] Weird interaction between `git -C`, aliases and worktrees","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-10-16T00:23:54Z","receivedAt":"2020-10-16T00:23:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 14, 2020 at 06:35:39PM -0400, Philippe Blain wrote:\n\n> I found two threads [2] and [3] which are manifestations of similar (or the same ?) problems...\n> \n> Maybe git-config(1) could document which variables will \n> be set in aliases that shell out, but even that might be tricky because it\n> seems the answer is \"it depends\" (according to [2])...\n> \n> I also found 57ea7123c8 (git.c: make sure we do not \n> leak GIT_* to alias scripts, 2015-12-20), in topic 'nd/clear-gitenv-upon-use-of-alias',\n> which tries to clear out GIT_* variables from aliases environment,\n> which I guess is defeated by the fact that I run `git -C` in my alias...\n> \n> Anyway thanks for your answer.\n> \n> [1] https://git-scm.com/docs/git#Documentation/git.txt---git-dirltpathgt\n> [2] https://lore.kernel.org/git/20200130102933.GE840531@coredump.intra.peff.net/\n> [3] https://lore.kernel.org/git/20200228190218.GC1408759@coredump.intra.peff.net/\n\nIMHO it is still worth doing a fix similar to what I wrote earlier. But\nsomebody needs to figure out what's up with the failure in t5601:\n\n - whether it's a behavior that has to be kept, or if it's something we can\n deprecate or just publicly warn about\n\n - if kept, can we work around it internally within git-clone /\n git-init? If not, can we work around it with an extra environment\n variable?\n\nI probably won't look at it anytime soon, but I'd be happy if somebody\nelse did. :)\n\n-Peff\n"}]}