git index containing tree extension for unknown path

Christian Halstrick· Jan 21, 2015, 16:14 UTC · lore

Is it allowed that the git index contains a tree extension mentioning patch 'x/y/z' while the only entry in the index is a '.gitattributes' files in the root?

I have such a repo in a bug report against JGit [1]. Native git has no problems with this repo but JGit can't read such an index. I am wondering whether such a index is valid.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=457152

Junio C Hamano· Jan 21, 2015, 20:39 UTC · re: Christian Halstrick · lore

Re: git index containing tree extension for unknown path

Christian Halstrick <christian.halstrick@gmail.com> writes:

> Is it allowed that the git index contains a tree extension mentioning
> patch 'x/y/z' while the only entry in the index is a '.gitattributes'
> files in the root?

Depends on the definition of "mention", but it is not unexpected that you see "x", "y", and "z" in the cache-tree extension as invalidated nodes after you do something like this:

	rm -fr test &&
        git init test &&
        cd test
        mkdir -p x/y/z &&
        >x/y/z/1 &&
        git add x &&
        git write-tree && # cache-tree is fully valid
        mv x/y/z x/y/a &&
        git add x # cache-tree invalidated

"z", if appears, should still know that "y" is its parent and "y", if appears, should still know that "x" is its parent. All of the three should say they have been invalidated by showing a negative entry-count and show the "correct" subtree count that appear in the extension (i.e. if "z" is there as an invalidated leaf, it should say "-1 0" to indicate an invalidated entry by a negative entry count, with zero subtrees, and "y" would show "-1 1" to indicate an invalidated entry with one subtree, namely "z", etc.).

Christian Halstrick· Jan 23, 2015, 06:23 UTC · re: Junio C Hamano · lore

Re: git index containing tree extension for unknown path

Thanks for the explanation. In my case it seems we have an invalid index. I modified the gin script [1] to inspect the index and found valid cached trees in the index for pathes for which the index has no entries. Will try to find out who/how the index was corrupted.

[1] https://raw.githubusercontent.com/chalstrick/gin/master/gin

Output of the script

> gin.py

[header]
  signature = DIRC
  version = 2
  entries = 1

[entry]
  entry = 1
  ctime = 1421834321.9923096
  mtime = 1420815554.0
  dev = 2049
  ino = 658461
  mode = 100644
  uid = 1000
  gid = 1000
  size = 42
  sha1 = 6c6909e2b92e763e890a9a42695680762802a50a
  flags = 14
  assume-valid = False
  extended = False
  stage = (False, False)
  name = .gitattributes

[extension]
  extension = 1
  signature = TREE
  size = 103

[cachedTree]
  name =
  entryCnt = 2
  subtreeCnt = 1
  id = f59374e16868ce8385b4ee602c737f917da4af1b

[cachedTree]
  name = a
  entryCnt = 1
  subtreeCnt = 1
  id = 4b5e60c30485a91ee60bd869ecc3b4d2b892fc3f

[cachedTree]
  name = b
  entryCnt = 1
  subtreeCnt = 1
  id = 50bd519cc418878d4b0ffc27348afd710c188d6d

[cachedTree]
  name = c
  entryCnt = 1
  subtreeCnt = 0
  id = 2b230fa0f3d19b497d3dd24e835691e3a921657f

[checksum]
  checksum = True
  sha1 = 124680d4dec4758ee1ae28f546659d282952ebff
Ciao
  Chris
Ciao
  Chris

On Wed, Jan 21, 2015 at 9:39 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 30 quoted lines

> Christian Halstrick <christian.halstrick@gmail.com> writes:
>
>> Is it allowed that the git index contains a tree extension mentioning
>> patch 'x/y/z' while the only entry in the index is a '.gitattributes'
>> files in the root?
>
> Depends on the definition of "mention", but it is not unexpected
> that you see "x", "y", and "z" in the cache-tree extension as
> invalidated nodes after you do something like this:
>
>         rm -fr test &&
>         git init test &&
>         cd test
>         mkdir -p x/y/z &&
>         >x/y/z/1 &&
>         git add x &&
>         git write-tree && # cache-tree is fully valid
>         mv x/y/z x/y/a &&
>         git add x # cache-tree invalidated
>
> "z", if appears, should still know that "y" is its parent and "y",
> if appears, should still know that "x" is its parent.  All of the
> three should say they have been invalidated by showing a negative
> entry-count and show the "correct" subtree count that appear in the
> extension (i.e. if "z" is there as an invalidated leaf, it should
> say "-1 0" to indicate an invalidated entry by a negative entry count,
> with zero subtrees, and "y" would show "-1 1" to indicate an
> invalidated entry with one subtree, namely "z", etc.).
>
>