Re: [GIT PULL] per signal_struct coredumps

Junio C Hamano [off-list ref] writes:

Linus Torvalds [off-list ref] writes:

quoted

The basic issue is how to sanely keep track of a cover letter when you
have a branch that you haven't sent out yet, but will ask somebody to
pull. It may still be seeing more testing and development before that
pull happens, though.

This very much smells of what the "branch description" is all about, but

 (a) I suspect "git branch --edit-description" is not very well known

True.

quoted

 (b) it works well with "git request-pull", but not so much some other
things (like copying it into a signed tag)

I think that is just a matter of programming ;-)

quoted

 (c) it makes an unholy mess of your config file if you actually use
it for extensive explanations (branch descriptions _work_ for
multi-line messages, but it really was designed as a one-liner thing).

Not, really.

The "-m" option similar to "commit/tag" is deliberately omitted and
use of editor is forced, to encourage better than one-liner
information.  cf. b7200e83 (branch: teach --edit-description option,
2011-09-20).

The unholy mess is true if you are in the habit of editing .git/config
in your editor, but that is to be expected if you are storing multi
paragraph description as a value of a configuration variable.

quoted

 (d) it doesn't work across repositories (ie multiple developers or
even just a single developer on multiple machines).

This is the biggest issue.

quoted

IOW, the "branch description" is _kind_ of the right thing, but not really.

43 more quoted lines

I think an empty commit at the top of a development branch sounds
like a nice place to store the cover letter for a set of changes.
That is a related problem but that is not the problem that inspired
the no-op merge commits.



I have not seen addressed the workflow that actually inspired this
odd thing I am doing.  So let me see if I can describe the problem
that inspired the merge commit more clearly.

Before the merge window for v5.17 I expect to be working on
a topic I will loosely call "do_exit_coredumps_and_signals".

There are going to be several changesets (something like):
"Move coredumps rendezvous into get_signal"
"Use the same exit code in all implementations of die"
"Use signal short circuit delivery for coredumps"
"Use signal short circuit delivery whenever possible"
"Replace do_exit with a different helper for use by die"

Each of those will consist of 5-10 patches and need to be individually
reviewed and depend upon each other.  In the roughly 2 months of
development time before v5.17 I can expect to get several of those
changesets.  Each changeset will depend upon the work of the changeset
before.

As each changeset is reviewed and finalized I expect I will put it on
the topic branch with a merge commit containing the description letter.
That merge commit will contain a "Link:" tag to the posting on the
mailing list so that people can find the full description.

When put into the topic branch after review the commits are frozen
and ready to be sent to Linus for merging, when the next merge window
opens.

52 more lines

ebiederm@xmission.com (Eric W. Biederman) writes:

I have not seen addressed the workflow that actually inspired this
odd thing I am doing.  So let me see if I can describe the problem
that inspired the merge commit more clearly.

Where can I learn more about the "fake" merge commit (assume I do
not know anything more than what Linus wrote in the message to the
git mailing list)?  Even after re-reading your description twice,
I get that you are using an extra merge commit as a place to store
the cover letter material, I am guessing that one of the parents
(which one???) is the tip of the finished "changeset" (I take the
word to mean "one of more commits on the same theme, in a single
strand of pearls"), but I am not sure what the other parent is to
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.

Before the merge window for v5.17 I expect to be working on
a topic I will loosely call "do_exit_coredumps_and_signals".

There are going to be several changesets (something like):
"Move coredumps rendezvous into get_signal"
"Use the same exit code in all implementations of die"
"Use signal short circuit delivery for coredumps"
"Use signal short circuit delivery whenever possible"
"Replace do_exit with a different helper for use by die"

Each of those will consist of 5-10 patches and need to be individually
reviewed and depend upon each other.  In the roughly 2 months of
development time before v5.17 I can expect to get several of those
changesets.  Each changeset will depend upon the work of the changeset
before.

Up to this point, I think I get what is going on.  You've worked
together with your reviewer and came up several patches to achieve
the "Move coredumps rendezvous into get_signal" task, so now you
have one topic branch that forks from some point in Linus's history
and houses these patches.  If "Use the same exit code" topic builds
on the "Move coredumps" one, the topic branch for the former may
fork from the tip of the latter.

As each changeset is reviewed and finalized I expect I will put it on
the topic branch with a merge commit containing the description letter.

This part I do not understand.  What is merged into what?  The tip
of the "Move coredumps" series of commits gets merged into the
previous stable release from Linus or some appropriate point inhis
history, and the topic branch points at that merge?

That merge commit will contain a "Link:" tag to the posting on the
mailing list so that people can find the full description.

If a signed tag were used to store that description and Link,
wouldn't that be sufficient?  Then Linus would pull that signed tag
to see it is from you, the merge would show which tag was merged and
what the tag said.  And we do not see the fake merge---I think the
maintainer's complaint and the problem the fake merge brings into
the history is that, while one of its parents, namely, the tip of
the "Move coredumps" series of commits, does have meaning, the other
parent does not.  It can be any ancient commit.

It _might_ make it a bit more palatable to Linus if the merit of
using a merge includes that the other parent can record the fork
point of the main series of commits (i.e. the merge will have to be
created with "merge --no-ff"), but I still feel that the argument is
weak, when a signed tag would work better (and I probably am missing
the use cases in which fake merges work better than signed tags).

When put into the topic branch after review the commits are frozen
and ready to be sent to Linus for merging, when the next merge window
opens.

When the development window closes and the merge window opens I will run
"git shortlog" see what is there and write up a description for the
entire topic branch.  Ideally I will put that into a signed tag etc
before I send it to Linus.

Here, what do you exactly mean by "the entire topic branch"?  For a
single "changeset" like "Move coredumps", or all of the changesets?

Assuming that the answer is the former, and assuming that the "topic
branch" for "Move coredumps" look like:

 a. it forks from some point in the upstream history;

 b. it build one or more commits on it, a single strand of pearls;

 c. it is capped with a (fake) merge to merge the above into some
    point in the upstream history;

what is missing from the Git toolset to turn the above two into a
signed tag that points at the tip of b. (i.e. without the fake
merge)?  Ideally, after b. is made, don't you want to go directly to
a signed tag, instead of a (fake) merge?

In the case that triggered this conversation I happened to only have a
single changeset with a single merge commit in the topic branch which
looks very odd, but that is mot definitely not the case I want to
optimize for.

It is unclear to me why the number of commits in the b. part
matters.  Be it one or 40, the (fake) merge at the tip seems
unnecessary, when the whole thing is merged into the upstream
history.

I seriously doubt that I am getting the whole requirement, as it
seems that "develop a series of commits on a branch, that may or may
not be dependent with each other, and ask the branch to be pulled by
giving the description in a signed tag that points at the tip of the
work" should work OK?

Junio C Hamano [off-list ref] 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

35 more lines

Junio C Hamano [off-list ref] writes:

                              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.