git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Feb 27, 2016, 03:22 UTC
Message-ID
<20160227032236.GA10313@sigill.intra.peff.net>
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
Previous: Junio C HamanoNext: Jeff King
Message 6 of 13 in “fix some rev-parse options in non-repos”
  1. 0/2 fix some rev-parse options in non-reposJeff King, Feb 26, 2016
  2. 1/2 t1515: add tests for rev-parse out-of-repo helpersJeff King, Feb 26, 2016
  3. 2/2 Revert "rev-parse: remove restrictions on some options"Jeff King, Feb 26, 2016
  4. Jeff KingFeb 26, 2016
  5. Junio C HamanoFeb 26, 2016
  6. Jeff KingFeb 27, 2016
  7. Jeff KingFeb 29, 2016
  8. Junio C HamanoFeb 29, 2016
  9. Jeff KingFeb 29, 2016
  10. John KeepingFeb 27, 2016
  11. Jeff KingFeb 29, 2016
  12. Eric SunshineFeb 28, 2016
  13. Jeff KingFeb 29, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.