Re: [GIT PULL] per signal_struct coredumps

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 18, 2021, 09:29 UTC
Message-ID: <xmqqk0h5yfq3.fsf@gitster.g>
In-Reply-To: <xmqq8rxobj1k.fsf@gitster.g>

Junio C Hamano <junio@pobox.com> writes:

Show 25 quoted lines

>                               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
> ...
> 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.

Addendum.

If you have only one topic (i.e. you do not have o-o and p-p-p in the above picture, but just o-o), then it would be quite strange to create M and offer it to the upstream, as M's first parent, as well as the bottom of the o-o chain, would be something the upstream has and the merge would look redundant from upstream's point of view, as they will be creating another merge of their tip and M, at which point they'd rather merge the topmost commit in the o-o chain directly without having to deal with M.