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

[Jeff King <peff@peff.net>]

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.

> >     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.

> >     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).

> >   - 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 <peff@peff.net>
> 
> 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