From: Jeff King <peff@peff.net>
To: "Michaël Fortin" <fortinmike@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Weird output of git status in pre-commit hook when providing a pathspec on commit
Date: Tue, 3 Feb 2015 11:32:35 -0500 [thread overview]
Message-ID: <20150203163235.GA9325@peff.net> (raw)
In-Reply-To: <80E24BA2-84FE-47FC-A5C0-D291E3C63BD5@gmail.com>
On Tue, Feb 03, 2015 at 08:14:06AM -0500, Michaël Fortin wrote:
> Repo1 has the following pre-commit hook:
>
> #!/bin/bash
> git -C "../Repo2" status --porcelain
>
> I then commit in Repo1 using the following (this is actually ran by a
> GUI, I have no control over the commands themselves):
>
> git add --force -- MyNewFile
> git commit -m "My message" -o -- MyNewFile
Because the commit command uses "-o", git must use a temporary index
file to stage the commit. It sets GIT_INDEX_FILE in the environment, and
then runs your hook.
When the hook runs "git -C" it moves into another repository, but the
GIT_INDEX_FILE in the environment takes precedence over the local index
found in that repository. So you see a HEAD and working tree from Repo2,
but the index from Repo1.
This is a specific case of a more general problem. If you were to run
git like:
git --git-dir=/path/to/.git commit ...
you would have similar problems. You would have $GIT_DIR set in the
environment, and would see the HEAD from Repo1, but the working tree
from Repo2.
In other words, moving into another git directory from inside a hook is
not as easy as just going there. You also need to clear any state from
the environment. E.g., by adding this to the top of your hook:
unset $(git rev-parse --local-env-vars)
Should "-C" (or "--git-dir") make this easier by doing it for you? I'm
not sure it is a good idea. It is right now valid to do:
GIT_INDEX_FILE=/path/to/index.tmp git -C /path/to/repo ...
which would break if we cleared git variables. OTOH, maybe using "-C"
(instead of chdir-ing yourself) is a good indication that you want that
cleared. I dunno. It is probably too late at this point, as we would be
subtly breaking backwards compatibility. Perhaps it would make more
sense to add a new option, so you could do:
git --reset-git-vars -C ../Repo2 status --porcelain
But this is a fairly obscure use case, and the rev-parse invocation
above is not so bad. I think it is more about knowing that you need to
use it, rather than the pain of typing it. And I am not sure how to make
that more clear. Is there a specific place in the documentation you
looked and might have been warned? Maybe the description for "-C" should
cover this.
-Peff
next prev parent reply other threads:[~2015-02-03 16:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-03 13:14 Weird output of git status in pre-commit hook when providing a pathspec on commit Michaël Fortin
2015-02-03 16:32 ` Jeff King [this message]
2015-02-04 22:45 ` Michaël Fortin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150203163235.GA9325@peff.net \
--to=peff@peff.net \
--cc=fortinmike@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).