On Thu, Jan 23, 2020 at 02:16:51AM +0000, Heba Waly via GitGitGadget wrote: > From: Heba Waly <heba.waly@xxxxxxxxx> > > git --git-dir <path> is a bit confusing and sometimes doesn't work as > the user would expect it to. > > For example, if the user runs `git --git-dir=<path> status`, git > will not be able to figure out the work tree path on its own and > will assign the work tree to the user's current work directory. > When this assignment is wrong, then the output will not match the > user's expectations. > > This patch updates the documentation to make it clearer. One thing Heba doesn't mention here is the effort she spent looking into how to give a similar hint in the form of an advise() call in cases when --git-dir is specified but --work-tree is not. While it's possible to show that kind of hint, it turns out to be tricky to decide whether the call in question actually wants the worktree. There was also some concern from Jonathan Tan around whether the hint would interfere with pre-existing user scripts which use --git-dir; since hints show on stderr, that interference is likely cosmetic, but still not great. That left me with a couple questions: - Is there a reason the advice library can't check whether it's pointing to an interactive shell, along the same lines as deciding whether to color output or not? - How do we generally worry about changes to stderr output in regard to user scripts? Is this as concerning as changes to stdout and return code, that is, for plumbing we do not change the format? > > Signed-off-by: Heba Waly <heba.waly@xxxxxxxxx> > --- > [Outreachy] git: update documentation for --git-dir > > git --git-dir is a bit confusing and sometimes doesn't work as the user > would expect it to. > > For example, if the user runs git --git-dir=<path> status, git will not > be able to figure out the work tree path on its own and will assign the > work tree to the user's current work directory. When this assignment is > wrong, then the output will not match the user's expectations. > > This patch updates the documentation to make it clearer. > > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-537%2FHebaWaly%2Fgit_dir_doc-v1 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-537/HebaWaly/git_dir_doc-v1 > Pull-Request: https://github.com/gitgitgadget/git/pull/537 > > Documentation/git.txt | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/Documentation/git.txt b/Documentation/git.txt > index b1597ac002..3b9402c742 100644 > --- a/Documentation/git.txt > +++ b/Documentation/git.txt > @@ -110,10 +110,15 @@ foo.bar= ...`) sets `foo.bar` to the empty string which `git config > Do not pipe Git output into a pager. > > --git-dir=<path>:: > - Set the path to the repository. This can also be controlled by > - setting the `GIT_DIR` environment variable. It can be an absolute > - path or relative path to current working directory. > - > + Set the path to the repository (i.e. the .git folder). This can also be > + controlled by setting the `GIT_DIR` environment variable. It can be > + an absolute path or relative path to current working directory. > + > + Note that --git-dir=<path> is not the same as -C=<path>. > + It's preferrable to set --work-tree=<path> as well when setting > + --git-dir to make sure Git will run your command across the correct > + work tree. I feel biased. I want to say, "In many cases, -C=<path> is easier to understand than --git-dir" instead. :) But my goal with sending this task to you was "convince people to use -C instead of --git-dir unless they're really sure" - which may or may not align with the sentiment of the rest of the list. - Emily
