Message-ID: <87lf1ob09z.fsf@email.froward.int.ebiederm.org>
Date:   Tue, 16 Nov 2021 09:14:32 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Junio C Hamano <junio@...ox.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Git List Mailing <git@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Kees Cook <keescook@...omium.org>,
        Linux API <linux-api@...r.kernel.org>
Subject: Re: [GIT PULL] per signal_struct coredumps

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

> Junio C Hamano <gitster@...ox.com> 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

Powered by blists - more mailing lists