Re: Notes on diffcore API
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jun 28, 2006, 07:36 UTC
- Message-ID
- <Pine.LNX.4.63.0606280934550.29667@wbgn013.biozentrum.uni-wuerzburg.de>
- In-Reply-To
- <7vbqse6unx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 27 Jun 2006, Junio C Hamano wrote:
Show 29 quoted lines
> "Alex Riesen" <raa.lkml@gmail.com> writes: > > > On 6/27/06, Junio C Hamano <junkio@cox.net> wrote: > >> -- >8 -- > >> Notes on diffcore API > >> ===================== > > > > Thanks! > > > >> Diffcore Transformation > >> ----------------------- > >> > >> The input file pairs recorded in the previous phase are > >> collected in diff_queued_diff (a global variable -- which means > >> that you cannot have two diffs running in parallel with the > >> current setup). This is an expandable array of pointers to > >> `struct diff_filepair` structure. > >> > > > > merge-recursive shouldn't have any problems with that, as the > > renames are just read in the current implementation. > > Still, it is somehow uncomfortable to see the amount of APIs > > with the above restriction. Never know when it'll bite. > > I think it is simply the matter of moving diff_queued_diff a > field in diff_optionss structure and adding an extra parameter > to point at the current diff_options to handful functions if we > ever need to support it. I haven't bothered doing that because > we haven't had the need to run more than one diff at once.
And we shouldn't bother until we need it. It has a small performance impact, and the code gets more ugly.
Ciao, Dscho