Junio C Hamano <gitster@xxxxxxxxx> writes:
> Sergey Organov <sorganov@xxxxxxxxx> writes:
>
>> Isn't it always the case that "mainline" is the first parent, as that's
>> how "git merge" happens to work?
>
> You may not be merging into the "mainline" in the first place.
>
> Imagine forking two topics at the same commit on the mainline, and
> merging these two topics of equal importance together into a single
> bigger topic, before asking the mainline to pull the whole.
>
> $ git checkout mainline
> $ git tag fork-point
> $ git checkout -b frontend-topic fork-point
> $ work work work
> $ git checkout -b backend-topic fork-point
> $ work work work
> $ git checkout -b combined
> $ git merge frontend-topic
> $ git tag merged
>
> The backend-topic may be recorded as the first-parent of the
> resulting merge, but logically the two topics are of equal footing,
> so merge^1..merge and merge^2..merge are both equally interesting.
Point taken, thanks! Now, if I reformulate my original question as:
"Isn't it _usually_ the case that "mainline" is the first parent?"
what is the answer?
For example, in the above case I'd likely rather:
$ git checkout -b combined fork-point
$ git merge --no-ff frontend-topic
$ git merge --no-ff backend-topic
and still have clear "mainline" on "-m1" for both merges.
I'm asking because those:
"Usually you cannot cherry-pick a merge because you do not know which
side of the merge should be considered the mainline."
in the manual page still feels confusing in the context of typical git
usage (as opposed to the context of abstract DAG operations where it'd
make sense indeed.)
-- Sergey
