Re: Getting an actuallt useful merge base?

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

>> It's like this
>>
>> T
>> ----o----o----o----o----o----o----o----o----o----o----o----o---(t)---o----o----
>>      \             \     \                                      \\\
>>       \             \     \                                      \\\
>>        \             \     \                                      \\\
>>         \        o----o----o\̶---o---(s)---o----o----o----o----o----o\̶\̶-(a)
>>          \      /            \      /                                \\
>> S+T  o----o----o----o----o----o----o----o----o----o----o----o----o----o\̶--(b)
>>     /                                       /                           \
>> ---o----o----o----o----o----o----o----o----o----o----o----o----o----o----o---(m)
>>
>> So (t) is common ancestor for (a) and (b) that merge-base reports but it is
>> only ancestor for files in set T, and does not have files from set S at all.
>> The common ancestor I am insterested in is (s) which is merge base for both
>> sets of files.
>
> From git-merge-base(1):
>
> "When the history involves criss-cross merges, there can be more than
> one best common ancestor for two commits...When the --all option is
> not given, it is unspecified which best one is output."
>
> Perhaps you want to specify --all to git merge-base, and then perform
> additional checks on the output to select one yourself?

Ignore me, as it is likely I am just confused, but if we are merging
(a) and (b), I do not think (s) could be usable as a merge base; it
may be an ancestor of (a) but is not an ancestor of (b), no?