On Tue, 4 Mar 2008, Jeff King wrote: > > I am tracking down a bug in unpack_trees, but I can't seem to find the > exact problem; I'm hoping to get help from people who have touched this > code a bit more than I have. Ok, so I decided that I should now finally go back and look at the original bug-report that triggered my unpack-trees rewrite, now that it's in a form where I feel like I can actually look at the code and fix the problem.. But when I just tested the bug-report case that Jeff described, it seems that I fixed the bug just with my cleanup. The current git "master" branch gives the following (incorrect) output for Jeff's script: [torvalds@woody repo]$ diff -u index1 index2 --- index1 2008-03-08 14:16:51.000000000 -0800 +++ index2 2008-03-08 14:16:51.000000000 -0800 @@ -1 +1,2 @@ df/file +new and with all my patches it just magically works correctly and the "git reset" correctly reset the index. So while I actually tried to be as careful as possible and do a minimal "convert to cleaner code" rather than actually fix the bug, it seems that just the cleanup actually did end up fixing it and there is nothing more to chase down. I'd love to say that I know what the original bug was, but since I couldn't fix it in the first place because I couldn't read the original code, I can't really say what fixed it. Jeff's test-script appended just for people who can't find the original message that started this all. Linus --- # make a repo mkdir repo && cd repo && git init # make a directory which will become a df conflict mkdir df echo content >df/file git add df/file git commit -m one # and save a copy of the index git ls-files >index1 # now make a new commit that has the df conflict and # a newly added file rm -rf df echo content >df git add df echo content >new git add new git commit -m two # now this should put our index exactly back to 'one' git reset --hard HEAD^ # but it doesn't git ls-files >index2 diff -u index1 index2 -- 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
