Junio C Hamano <junio@xxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> make that a "merge". If it is "fake", I guess that any random point
>> in Linus's history would do, but I can understand that the maintainer
>> would complain about such a seemingly unnecessary (back) merge.
>
> Having thought about it a bit more, I am not sure if these merges
> are truly "fake", or just a normal part of distributed development.
>
> As a degenerated case, first I'd imagine you have a patch series
> that focuses on a single "theme". You perfect the patches, you fork
> a topic branch from an appropriate "public" commit of your upstream
> (e.g. the last stable release from Linus), you add a signed tag at
> the tip of that topic branch, and you ask a (subsystem) maintainer
> to pull from you. The subsystem maintainer's tree will have series
> of merges to collect work from other people working in the subsystem
> ('x'), and the pull from you will create a merge whose first parent
> is one of these 'x' (i.e. the work by the maintainer so far), and
> the second parent of it is the tip of your work. The merge commit M
> gives a detailed description of what happend on the side branch and
> its mergetag header carries the contents of the tag you created for
> the pull request.
>
> \ \
> ---x---x---M
> / Subsystem maintainer pulls from you
> /
> ...---o---o (your work)
>
> Your next topic, which is a chunk of the same larger theme, may
> depend on what you did in the commits in this initial series 'o'.
>
>
> \ \ \ \
> ---x---x---M---x---x---N
> / / Subsystem maintainer pulls from you again
> / /
> ...---o---o---p---p---p (your second batch)
>
>
> Eventually, this will be pulled into Linus's tree when the subsystem
> maintainer is ready to send the whole thing.
>
> Y--- (Linus's tree)
> / Linus pulls from subsystem maintainer
> \ \ \ \ /
> ---x---x---M---x---x---N (Subsystem maintainer's tree)
> / /
> / /
> ...---o---o---p---p---p (Your tree)
>
> The above picture only depicts two topics, one directly building on
> top of the other, from you, but that is simplified merely for
> illustration purposes. The real history may have more topics, some
> are dependent on others, while some are independent.
>
> Now, if you have many related but more or less independent topic
> branches that will support a larger theme, it would be quite natural
> if you acted as your own "subsystem" maintainer, in other words, in
> the above picture:
>
> . you are in control of not just the bottom line, but in the middle
> line of development;
>
> . you do not have 'x' that merges from other people;
>
> . but you do have M and N, and use these merges just like a
> subsystem maintainer would use to describe the work done in the
> side branches.
>
> and offer 'N' as the tip of a "larger" topic that has internal
> structure, not just a single strand of pearls, by adding a signed
> tag on 'N' and throwing a pull request at Linus (or whoever is
> immediately above your level).
>
> Is that what happened (as I said, I lack context)? If so, I do not
> see much problem in the situation. But this assumes that these so
> called "fake" merges are merging into right first parents.
Yes. I write and post the patches with my developer hat on,
and I merge them with my maintainer hat on, then ultimately I send
them to Linus with the same maintainer hat on.
The full email conversation is at:
https://lore.kernel.org/all/878ry512iv.fsf@disp2133/T/#u
Here is where Linus merged the change:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a602285ac11b019e9ce7c3907328e9f95f4967f0
In this specific case it is a very degenerate case as there was only one
set of changes.
The one difference from my work flow and the one you described
is that I haven't reach the point of signing my pull requests.
In general and especially this cycle I intend to have multiple
changesets each with their own merge commit delineating them. Short of
being informed of a better way to work.
I suspect the conversation is simply because the pull request was
sufficiently degenerate that things just looked really weird. But I am
open to learning otherwise.
Eric
