Re: Help with new GCC git workflow...

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Wed, 15 Jan 2020 at 08:40, Richard Biener <richard.guenther@gmail.com> wrote:
> >
> > On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond <esr@thyrsus.com> wrote:
> > >
> > > Peter Bergner <bergner@linux.ibm.com>:
> > > > At this point, I get a little confused. :-)  I know to submit my patch
> > > > for review, I'll want to squash my commits down into one patch, but how
> > > > does one do that?  Should I do that now or only when I'm ready to
> > > > push this change to the upstream repo or ???  Do I need to even do that?
> > >
> > > If you want to squash a commit series, the magic is git rebase -i. You
> > > give that a number of commits to look back at at and you'll get a buffer
> > > instructing you how to squash and shuffle that series.  You'll also be able
> > > to edit the commit message.
> > >
> > > I like to write really fine-grained commits when I'm developing, then
> > > squash before pushing so the public repo commits always go from "tests
> > > pass" to "test pass".  That way you can do clean bisections on the
> > > public history.
> >
> > The question is wheter one could achieve this with branches?  That is,
> > have master contain a merge commit from a branch that contains the
> > fine-grained commits?  Because for forensics those can be sometimes
> > useful.
>
> A "merge commit" is a special kind of commit that creates a commit
> with two (or more) parents, and joins two separate trees. We don't
> allow that in master or release branches.
>
> But you can definitely take a series of commits from a branch and put
> that whole series into master, without squashing them into one commit.
> You just have to rebase the patches onto master (or cherry-pick each
> one of the series in turn, but rebase is easier for multiple patches).
> That makes a series of new commits on master, each one corresponding
> to one of he commits in the branch (but new commits with new hashes,
> because the new commit has a different parent than the one on the
> branch did). That's fine, but it's not a "merge commit".
>
>
> > That basically would somehow record that a series of commits are "related"
> > (the merge commit has two parents).  Of course usually the merge commit
> > is empty and thus non-existant but then for branch merges it still
> > always exists?
>
> A merge commit might be empty, but it's not non-existent. But we don't
> allow merge commits on master, and we don't need to allow them in
> order to have a series of related commits go in together.

OK, I see.  Guess we should document to not think that a git push
of a series represented as multiple commits are a "single" commit
on master then and that if you do that individual commits need to be
bootstrapped and tested.  So, maybe prevent pushes of multiple
commits for safety?

As for not allowing merges I guess we could eventually relax this
to allow merge commits that are "empty" and the referred refs
have linear history from the merge parent?

Richard.