Help with new GCC git workflow...

[Jonathan Wakely]

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 <jwakely@redhat.com>
     Date:   Tue Jan 14 22:32:45 2020 +0000

         3rd commit message

     commit 3d4a8783ba7f6d466d1729b59436a96b67ddf516
     Author: Jonathan Wakely <jwakely@redhat.com>
     Date:   Tue Jan 14 22:32:40 2020 +0000

         2nd commit message

     commit e0a27b98135936d4129876babdbe81e22e6e9bbf
     Author: Jonathan Wakely <jwakely@redhat.com>
     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.