Re: [PATCH v2 03/11] merge-index: libify merge_one_path() and merge_all()

From: Alban Gruin <alban.gruin@gmail.com>
Date: Sep 2, 2020, 15:37 UTC
Message-ID: <6e16673b-2c66-ddaf-5dec-abdd770adcff@gmail.com>
In-Reply-To: <xmqqft81cidt.fsf@gitster.c.googlers.com>

Le 01/09/2020 à 23:11, Junio C Hamano a écrit :

Show 17 quoted lines

> Alban Gruin <alban.gruin@gmail.com> writes:
> 
>> The "resolve" and "octopus" merge strategies do not call directly `git
>> merge-one-file', they delegate the work to another git command, `git
>> merge-index', that will loop over files in the index and call the
>> specified command.  Unfortunately, these functions are not part of
>> libgit.a, which means that once rewritten, the strategies would still
>> have to invoke `merge-one-file' by spawning a new process first.
>>
>> To avoid this, this moves merge_one_path(), merge_all(), and their
>> helpers to merge-strategies.c.  They also take a callback to dictate
>> what they should do for each file.  For now, only one launching a new
>> process is defined to preserve the behaviour of the builtin version.
> 
> ... of the "builtin" version?  I thought this series is introducing
> a new builtin version?  Puzzled...
>

`merge-index' is already a builtin, this step libifies it. Its core feature is to call repeatedly a command (usually it's `git-merge-one-file'), but the new version will call a callback instead, so its behaviour is not hardcoded. This patch only provides a callback starting a new command to preserve its behaviour.

Perhaps rewording the last sentence like this would be better?

  For now, only one launching a new process is defined, to preserve the
behaviour of `merge-index'.