On 1/15/20 4:55 AM, Jonathan Wakely wrote:
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.
The only point is the grouping richi mentions.
To that purpose we *could* allow --no-ff merges that otherwise would
have been fast-forward, but allowing such merges without allowing any
other merges would be difficult to enforce. I don't think it's worth
bothering.
Jason
