On Wed, 15 Jan 2020 at 08:40, Richard Biener <richard.guent...@gmail.com> wrote: > > On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond <e...@thyrsus.com> wrote: > > > > Peter Bergner <berg...@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.
