Linus Torvalds, Tue, Jun 27, 2006 01:54:18 +0200: > > > > To my deep disappointment, it didn't work out as good as I hoped: one > > program I see most often and for longest time in the process list > > (git-diff-tree) is a too complex thing to be put directly into > > merge-recursive.c, so any help in this direction will be greatly > > appreciated. > > Are you sure? > > git-diff-tree is one of the simplest git operations. We've got absolutely > _tons_ of infrastructure in place to do it efficiently, since it's done > all over the map (a "git-rev-list" with path limiting will do a diff-tree > against all the commits). > > Some of the interfaces might be a bit non-obvious, but the diff stuff was > some of the first ones to be libified exactly because they end up being so > fundamental. > That (non-obvious) was actually the problem here. I needed a diff-tree without any output on stdout, with "-M" (rename detection). The precise command I gave up to implement was: git-diff-tree -M --diff-filter=R -r -z <tree1> <tree2> I stopped somewhere around diff_tree, being confused by show_entry. I took a look at it again, and it seem that show_entry does not actually "show" anything but calls diff_options->add_remove, right? So I could define my callback, setup the options (which I certanly can find after looking closer and longer at builtin-diff-tree.c) and wrap diff_options with my own struct (I need to pass arguments to the callback reentrantly: it is a recursive algorithm). Well, it wasn't that clear (unless I missed something by a mile) last week... But thanks for you suspicions, they actually forced me to look at diff-tree again. Will do ... unless (I hope) someone beats me to it. Bye! - : 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