Re: git describe oddity with GIT_DIR

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

 



Am 16.10.2014 um 18:57 schrieb Junio C Hamano:
> Thomas Braun <thomas.braun@xxxxxxxxxxxxxxxxxxx> 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 :)

--
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]