Subject: Re: [Internet]Re: [PATCH v7 1/2] merge-tree.c: add --merge-base=<commit> option

From: Junio C Hamano <[email-masked]>
Date: Tue, 22 Nov 2022 14:42:10 +0900

Junio C Hamano <[email-masked]> writes:

> "kylezhao(赵柯宇)" <[email-masked]> writes:
>
>> I went to check the api-parse-option.txt, but I didn't found an
>> elegant solution to stop when the users uses the second
>> "--merge-base".
>
> That's not even a fix, as it does not allow specifying more than one
> merge bases, is it?
>
> Just like how builtin/merge-tree.c::real_merge() is prepared to
> handle parent1 and parent2 that have multiple merge bases and pass
> all of them to the underlying merge machinery, you can accumulate
> multiple strings using OPT_STRING_LIST() and use all of them as
> merge_bases, no?

I am a bit torn on this, though.  

Because it uses lookup_commit_reference_by_name() to obtain
base_commit in addition to parent1 and parent2, and then
get_commit_tree() on them to get their trees, the real_merge()
function in the posted patch is incapable of accepting a single
"pretend as if this tree object is the common ancestor tree" and
merging the two tree objects.  But once that flaw is fixed, using
merge_incore_nonrecursive() with an explicitly given "base", we can
merge totally trees regardless of how the commits they are found in
are related in the history, which is a very logical thing to do.
And while operating in that mode, there is no way to accept more
than one "base".

So, I would be PERFECTLY HAPPY if this new mode of operation can
take only one "base" tree object, if it allows BASE, PARENT1,
and PARENT2 to be all tree objects, not necessarily commit objects.

But if we insist that PARENT1 and PARENT2 must be commits, then I
would find it very unsatisfying if we only took a single BASE that
also must be a commit.  If the merge-base has to be a tree or trees,
then there is no way to perform recursive merge (because you cannot
compute common ancestors across tree objects) , so it is perfectly
justifiable to take only a single base (and error out upon seeing a
second --merge-base=X option).

But it has to be a commit, then there is no justification to forbid
recursive operation, and I do not see a good reason to take only one
COMMON thing.

So, it is easy to say "let's take the current patch as a good first
step", but it is unclear what the good second step would be.

We could correct the code to allow PARENT1, PARENT2 and BASE to be
tree objects, not necessarily commits, when only a single merge-base
is specified.  That corrects the current flaw that tree objects
cannot be used.  And then when more than one BASE is given (or no
BASE is given---which is the original code), we could correct the
code to call merge_incore_recursive() instead.

But the amount of the effort to get there from the current codebase
(without your patch) feels more or less the same ballpark as the
patch in question, so...