Message-ID: <xmqq8rxobj1k.fsf@gitster.g>
Date:   Tue, 16 Nov 2021 00:29:11 -0800
From:   Junio C Hamano <junio@...ox.com>
To:     ebiederm@...ssion.com (Eric W. Biederman)
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 <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.

Powered by blists - more mailing lists