This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with new GCC git workflow...

On 14/01/20 17:05 +0000, Jonathan Wakely wrote:
On 14/01/20 10:07 -0600, Peter Bergner wrote:
As somewhat of a git newbie and given gcc developers will do a git push of
our changes rather than employing a git pull development model, I'd like
a little hand holding on what my new gcc git workflow should be, so I don't
screw up the upstream repo by pushing something to the wrong place. :-)

I know enough that I should be using local branches to develop my changes,
so I want something like:

git checkout master
git pull
git checkout -b <branchNameHere>
<modify and add new files>
git commit -m "My commit message1"
<modify and add new files>
git commit -m "My commit message2"
<modify and add new files>
git commit -m "My commit message3"
<all done!>

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?

This is Git, there are a hundred ways ;-)

Should I do that now or only when I'm ready to
push this change to the upstream repo or ???

Totally up to you. You might want to squash some commits early, e.g.
to fix silly typos, but keep most of the branch history intact until
the last minute (to help you remember what you changed and why).
That's my preference.

Do I need to even do that?

If it's a long-lived feature branch you might want to keep the
separate commits and merge them all to master preserving the branch
history (don't take my word for it, I can't remember what we decided
should be the policy for such long-lived branches).

If it's just a short-lived branch to change one thing, or fix one bug,
then what you push should be a single, self-contained commit (even if
you happened to develop it as a series of mini-commits locally).

Also, when I'm ready to push this "change" upstream to trunk, I'll need
to move this over to my master and then push.

Strictly speaking, you don't need to. You can push that branch
directly to master:  git push origin HEAD:master
That will fail unless the current branch is up-to-date with master,
but would work fine if you've already rebased your branch on master,
or if master hasn't moved since you branched.

What are the recommended
commands for doing that?  I assume I need to rebase my branch to
current upstream master, since that probably has moved forward since
I checked my code out.

You can either rebase on the new master (i.e. bring the new stuff from
master into your branch) or the other way around (bring the stuff from
your branch into master).

A pretty straightforward way to do the second way is:

git checkout master
git pull
git merge --squash <branchNameHere>
[resolve any merge conflicts]

I forgot to say that you'll need to do 'git commit' after the merge,
whether or not there were conflicts to resolve.

When you merge with --squash it adds the squashed result to the
"index" (i.e. staging area for changes to be committed) but stops
before the actual commit.

When you do the commit Git will start the commit message with all the
individual commit messages from the branch:

    Squashed commit of the following:
commit d308da36d957feb3736be2754d134926992b3b74
    Author: Jonathan Wakely <>
    Date:   Tue Jan 14 22:32:45 2020 +0000

        3rd commit message

    commit 3d4a8783ba7f6d466d1729b59436a96b67ddf516
    Author: Jonathan Wakely <>
    Date:   Tue Jan 14 22:32:40 2020 +0000

        2nd commit message

    commit e0a27b98135936d4129876babdbe81e22e6e9bbf
    Author: Jonathan Wakely <>
    Date:   Tue Jan 14 22:32:34 2020 +0000

        1st commit message

So that's a good time to produce the final commit message, cutting and
pasting bits from those if needed, or just deleting those lines.

However, on IRC some people are saying that the simple workflow we
should be advising for newbies is to rebase and squash on the branch
(maybe using Jason's 'git reset' command) and then cherry-pick that
onto master (instead of squash-merging). A cherry-pick takes a single
commit from another branch and applies it to the current branch,
roughly equivalent to creating a patch and then manually applying it.

[build + test again if your branch was behind master]
git push

i.e. pull the changes from your branch onto master, then push.

This leaves your <branchNameHere> branch untouched, so you still have
all the history locally for future reference.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]