On Wed, 15 Jan 2020 at 09:49, Richard Biener <richard.guent...@gmail.com> wrote: > > On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely <jwakely....@gmail.com> > wrote: > > > > 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. > > 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
Well yes, because if you push a series of commits then you push ... a series of commits. When you push something upstream you make the upstream repo have exactly the same commits as you have locally. There is no squashing or flattening involved. The remote repo's HEAD becomes the same commit ID as your HEAD. (Before an expert corrects me: strictly speaking, the remote's branch becomes whatever you push, which doesn't have to be HEAD because you could do 'git push origin some_commit_hash:master' but in the common case you just push your HEAD and that becomes the new branch tip on the remote). >then and that if you do that individual commits need to be > bootstrapped and tested. So, maybe prevent pushes of multiple > commits for safety? Please no! > 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? There's no point. If you have a simple linear history where each commit has a single parent, there is no merge commit. I highly recommend this video, to understand the Git model: https://www.youtube.com/watch?v=1ffBJ4sVUb4 I know it's long, but it's really worth it.
