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

Re: git rev-parse --show-toplevel inside `.git` returns 0 and prints nothing

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 19, 2019, 02:52 UTC
Message-ID
<xmqqk17wziex.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<CA+dzEBmrMavFJeyPSQr2wA9kFZwz_Kfr6PFBLRfLJ-EuCVXJnA@mail.gmail.com>
Anthony Sottile <asottile@umich.edu> writes:
Show 6 quoted lines
> I would expect it to either:
> - exit nonzero
> - produce the full path to the root of the repository
>
> would a patch be accepted which changes it to do one of those two
> things? I'd be happy to contribute such a patch

The most important invariant for the "--show-toplevel" and the "--show-prefix" options was that when they are concatenated the result matches the current directory in a working tree. So I think the result is undefined when you are not anywhere in the working tree.

Having said that, as scripts that want to know if they are inside .git directory (either directly in it, or in its subdirectories) should not be relying on the behaviour, and instead be using the "--is-inside-git-dir" option, I suspect that it won't be too disruptive to change the behaviour after all these years.

But it is no longer year 2007 and with widespread use of Git, it is almost guaranteed to break somebody's script ;-)

If I were designing the feature today, with today's rest-of-git in mind, I would say

 - In a bare repository, exit with non-zero status after giving an
   error message "no working tree".
 - In a repository that has a single associated working tree, show
   the path to the top-level of that working tree and exit with zero
   status.

In a repository that has more than one working trees (which is one of the things "todasy's rest-of-git" has that did not exist back when --show-prefix/--show-toplevel etc. were invented), then what? Would it make sense to show the primary working tree? What if the worktree(s) were made off of a bare repository, in which case nobody is the primary?

If we were changing "--show-toplevel", we may need to make changes to "--show-prefix" to things consistent, but I am not sure what it should say when run outside a working tree. It should continue to give nothing; it may make sense to exit with non-zero status, but I'd rather let sleeping dogs lie. Nobody is hurting by the command exiting with zero status (the same question applies to the "--show-toplevel" option, for that matter, though), when the result is undefined.

So...  I dunno.
Previous: Anthony SottileNext: Jeff King
Message 2 of 6 in “git rev-parse --show-toplevel inside `.git` returns 0 and prints nothing”
  1. Anthony SottileNov 18, 2019
  2. Junio C HamanoNov 19, 2019
  3. Jeff KingNov 19, 2019
  4. Anthony SottileNov 19, 2019
  5. Jeff KingNov 19, 2019
  6. Jeff KingNov 19, 2019

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.