git index containing tree extension for unknown path

git index containing tree extension for unknown path

[Christian Halstrick]

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

Re: git index containing tree extension for unknown path

[Junio C Hamano]

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.).

Re: git index containing tree extension for unknown path

[Christian Halstrick]

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:
> 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.).
>
>