Re: [RFC/PATCH] log: add log.firstparent option

On Thu, Jul 23, 2015 at 03:14:50PM -0700, Stefan Beller wrote:

Github pull request messages
are similar to cover letters, so you could send a series with a
good cover letter, but crappy unfinished patches inside the series.
After applying all patches it could be all nice, i.e. compiles, tests, adds the
new functionality. It might be just a commit in between which may not even
compile. That's my understanding of the messy-workflow.

Yeah, that's certainly one messy workflow. There are many levels of
messy. But I think fundamentally it comes down to: do you show the steps
that went into the result, or do you squash them out into a clean
history?

Gerrit cannot provide such a workflow easily as it's rather commit
centric and not branch centered. So you need to approve each
commit on its own and until 2 weeks ago you even needed to submit
each commit. (By now Gerrit has learned to submit a full branch, that
is you submit a commit and all its ancestors will integrate as well if they
were approved.)
Previously when the ancestors were not approved the commit would be
"submitted, merge pending", so it would wait for each commit to be approved
and submitted.
And because of this commit-centric workflow, the crappy commit in the series
is put into spot light.

Yeah, I agree that does not sound quite the same as the GitHub flow.

quoted

    So I think this could easily be improved by GitHub (we
    have the PR subject and body, after all). It's harder
    for a mailing list project like git.git, because Git
    never actually sees the subject line. I think it would
    require teaching git-am the concept of a patch series.

This would be cool I would imagine.

I talked with some GitHub folks about this. One of the challenges is
that the PR body is in Markdown, but we'd probably want "real" text in
the merge commit. One option would be to simply convert
Markdown->HTML->Text, which should provide a fairly clean version. It
will take some playing with, but I'm going to see what I can do.

quoted

    I don't know offhand what Gerrit merges look like.

Let's say it's complicated. Depending on configuration a few things
may happen. There are different integration strategies
* merge always
* merge if necessary (fastforward else)
* fastforward only
* rebase if necessary (to make it a linear history)
* cherrypick (which may add footers like Reviewed-by: to have that
information in the git history)

I think the "merge always" strategy would comfort from this patch.

Yeah, I think for anything else it's not a good idea (especially if you
fast-forward onto master).

quoted

  - we already have merge.ff to default to making extra
    merge commits. And if you use GitHub's UI to do the
    merge, it uses --no-ff. I don't think we would want
    these to become the default, so there's probably nothing
    else to be done there.

Signed-off-by: Jeff King <redacted>

The signoff is better placed above :)

Whoops. Usually I "format-patch -s" and then add any notes while
sending. But the wifi at OSCON was so abysmal that instead I wrote the
notes directly into the commit message to send the whole thing later.
And of course format-patch is not smart enough to know that I meant
everything after the "---" as notes. :)

-Peff