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

Re: git describe oddity with GIT_DIR

From
Thomas Braun <thomas.braun@virtuell-zuhause.de>
Date
Oct 16, 2014, 19:27 UTC
Message-ID
<54401C31.5090209@virtuell-zuhause.de>
In-Reply-To
<xmqq1tq8uf4f.fsf@gitster.dls.corp.google.com>
Am 16.10.2014 um 18:57 schrieb Junio C Hamano:
Show 54 quoted lines
> Thomas Braun <thomas.braun@virtuell-zuhause.de> writes:
> 
>> I've encountered an oddity with git describe.
>> Consider the following snippet:
>> -----
>> mkdir test
>> cd test
>> git init
>> echo 1 > file
>> git add file
>> git commit -m "changes"
>> $ git describe --always --dirty
>> 8ad486e
>> $ cd ..
>> $ git --git-dir=test/.git describe --always --dirty
>> 8ad486e-dirty
>> $ GIT_DIR=test/.git git describe --always --dirty
>> 8ad486e-dirty
>> -----
>>
>> The "-dirty" suffix appears if invoking git not from the worktree
>> itself, but should actually never appear.
> 
> This is not oddity with describe.  You are using --git-dir incorrectly.
> 
> When you tell Git where its repository resides with the $GIT_DIR
> environment variable or the --git-dir command-line option, unless
> you tell it where the top-level of your working tree is, you are
> telling that your current working directory is the top-level of your
> working tree.
> 
> You are asking "git describe" to describe the state of the HEAD
> including the dirtyness of the working tree in various ways.  With
> the first invocation, you do not tell Git where things are and let
> it correctly figure it out, i.e. you are in 'test' directory and
> relative to where you are, ".git" is the repository and "." is the
> top of the working tree.  The commit recorded in the ".git/HEAD",
> i.e. 8ad486e, is used, and its compared with the working tree to
> determine dirtiness.  Specifically, the blob object 8ad486e:file is
> the same as "./file" (that is "test/file" relative to where you
> started with "mkdir test" above).
> 
> With the latter two, you are asking the same question but you go one
> level up and then tell Git that the repository is "test/.git"
> (correct) and the top of the working tree is "." (a lie).  Again,
> "test/.git/HEAD" records the same commit, but when trying to compare
> the contents of its tree, e.g. "file" at the top-level in the
> commit, you do not have "file" in the working tree.  Git is led to
> believe that you removed "file", hence your working tree state is
> dirty.
> 
> Make it a habit to always specify GIT_WORK_TREE when you use
> GIT_DIR, unless you know you will always start from the top of the
> working tree.

Thanks a lot Junio for the in-depth explanation. I'll promise to do more research next time :)

Previous: Junio C Hamano
Message 3 of 3 in “git describe oddity with GIT_DIR”
  1. Thomas BraunOct 16, 2014
  2. Junio C HamanoOct 16, 2014
  3. Thomas BraunOct 16, 2014

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.