On Sat, 12 Jan 2008, Linus Torvalds wrote: > It makes builtin-commit.c use the same logic that "git read-tree -i -m" > does (which is what the old shell script did), and it seems to pass the > test-suite, and it looks pretty obvious. The only issue I know about with using unpack_trees in C as a replacement for read-tree in shell is that unpack_trees leaves "deletion" index entries in memory which are not written to disk, but may surprise some code (these are used to allow -u to remove the files from the working tree). So you may want to make sure that you don't get any weird results out of a commit of particular files that involves not committing some newly-added files: $ git add new-file $ (edit old-file) $ git commit old-file This may cause the unpack_trees to leave a misleading entry for new-file that the code doesn't expect. I've got a patch to make it saner as part of my builtin-checkout series, but I can't say for sure that that change won't either confuse something else or have performance problems without a bunch of analysis I haven't done recently. -Daniel *This .sig left intentionally blank* - 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
