From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>,
John Keeping <john@keeping.me.uk>
Subject: Re: [PATCH 2/2] Revert "rev-parse: remove restrictions on some options"
Date: Fri, 26 Feb 2016 22:22:37 -0500 [thread overview]
Message-ID: <20160227032236.GA10313@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqbn73hwam.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 26, 2016 at 03:44:01PM -0800, Junio C Hamano wrote:
> But why do you even need to run local-env-vars from outside a
> repository in the first place?
The short answer is: because it is about clearing the state to move into
a new repository, and we do not necessarily know what the old state was.
Here's a longer answer.
We (GitHub) have some scripts that preemptively clear the git env when
moving into another repository directory, so that the environment
doesn't lead to us operating in the wrong repository.
For example, we use alternates to share object storage between a series
of forks. So frequently in such scripts we may need to switch between
repositories (e.g., to sync a fork to the shared storage, and then go
back to the shared storage and run repack). To do so safely, we have to
clear the git env for each "cd" (otherwise things work fine when
$GIT_DIR is not set and we rely on auto-finding the repo, and break
horribly if the script is run with $GIT_DIR set).
There are a few corner cases where library code wants to "cd", but
doesn't know if it's coming from another repo or not. So it clears the
git env to be on the safe side. We could fix it by always going to the
new repo and running "unset $(git rev-parse --local-env-vars)" there,
but I think that just has the opposite problem (you may be _leaving_ a
repository, and want to make sure you are no longer in one).
For us, it's mostly just an annoyance. rev-parse produces no output so
we don't clear any variables, and its stderr gets logged somewhere. We
really only care about $GIT_DIR, and if that is set to something valid,
then you are in a repo, rev-parse works, and we clear it. But you can
come up with cases where it does the wrong thing, like:
# Work in some repo; set some git vars in the environment, but
# rely on auto-discovery to find the actual repo.
cd some-git-repo
export GIT_WORK_TREE=/whatever
git ...
# Now go back to our root and do some work elsewhere.
# We're no longer in a git repo.
cd ..
... run some non-git commands ...
# Now we want to go into a new repo. Clear the environment.
unset $(git rev-parse --local-env-vars)
cd ../another-git-repo
git ...
In the third directory, you'd still have GIT_WORK_TREE set, even though
you asked to clear existing git state.
I don't think we have any scripts that do that, but it doesn't seem that
implausible to me.
-Peff
next prev parent reply other threads:[~2016-02-27 3:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 23:25 [PATCH/RFC 0/2] fix some rev-parse options in non-repos Jeff King
2016-02-26 23:26 ` [PATCH 1/2] t1515: add tests for rev-parse out-of-repo helpers Jeff King
2016-02-26 23:29 ` [PATCH 2/2] Revert "rev-parse: remove restrictions on some options" Jeff King
2016-02-26 23:34 ` Jeff King
2016-02-26 23:44 ` Junio C Hamano
2016-02-27 3:22 ` Jeff King [this message]
2016-02-29 11:01 ` Jeff King
2016-02-29 17:32 ` Junio C Hamano
2016-02-29 21:29 ` Jeff King
2016-02-27 12:25 ` John Keeping
2016-02-29 11:11 ` Jeff King
2016-02-28 0:53 ` Eric Sunshine
2016-02-29 11:12 ` Jeff King
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=20160227032236.GA10313@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@keeping.me.uk \
--cc=mhagger@alum.mit.edu \
/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).