Christian Halstrick [off-list ref] 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.).
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 [off-list ref] wrote:
Christian Halstrick [off-list ref] writes:
quoted
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.).