Re: [GIT PULL] per signal_struct coredumps

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

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.