Re: [PATCH 2/2] Revert "rev-parse: remove restrictions on some options"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]