Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Thu, 23 Aug 2007, Marius Storm-Olsen wrote: >> >> I have an issue with git-rebase failing on a repository using >> core.autocrlf=true >> >> I've tracked it down to git-am failing with core.autocrlf=true and passing >> with core.autocrlf=false. I've tried digging deeper into the code, but for >> some reason ce_match_stat_basic() (read-cache.c:~187) reports the size of the >> file in the index to be 0 (when core.autocrlf=true), which is why git-am bails >> out on the patch. (ce->ce_size == 0, while st->st_size == the correct size on >> disk) > > Very interesting. > ... > trace: built-in: git 'apply' '--allow-binary-replacement' '--index' '.dotest/patch' > trace: built-in: git 'diff' '--quiet' > trace: built-in: git 'diff' '--quiet' > trace: built-in: git 'write-tree' > trace: built-in: git 'diff' '--quiet' > > ie everything was fine after the "apply" phase, but the index and the > working tree went out-of-kilter after "git write-tree". > > The reason? "git write-tree" doesn't read the config file, so it never > even reads the "core.autocrlf=true" variable. As a result, it seems to > screw up the index matching when it does the cache_tree_fully_valid() > (which will fail due to "git apply --index" having invalidated the tree > SHA1's) followed by cache_tree_update(). > >> Can anyone please enlighten me on why this may happen? > > This patch should fix it. > > Junio - it fixes the test for me, but quite frankly, I don't see why > write-tree would *ever* change any non-tree index entries. But it does. I > think there's another bug somewhere, or I'm missing something. As you said, there is something else going on. write-tree is about reading the index entries and writing them out as a set of trees, and at that point it should not even matter if you have garbage in the work tree or if you do not even have a work tree. All the crlf conversions have been done when the object hit the index, so its reading or not reading core.autocrlf should not change its behaviour. - 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
