Re: CFT: merge-recursive in C

From: Alex Riesen <fork0@t-online.de>
Date: Jun 27, 2006, 00:17 UTC
Message-ID: <20060627001732.GC3121@steel.home>
In-Reply-To: <Pine.LNX.4.64.0606261652350.3927@g5.osdl.org>

Linus Torvalds, Tue, Jun 27, 2006 01:54:18 +0200:

Show 18 quoted lines

> > 
> > 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!