Help with new GCC git workflow...

[Jason Merrill]

On 1/14/20 5:45 PM, Jonathan Wakely wrote:
> 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)

Probably easiest to focus on rebase -i.  And perhaps git add -p for 
splitting a commit.

> 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.

If the branch has been reshaped to be all master-ready commits, you can 
push the branch directly, or rebase your local master on top of it 
rather than cherry-pick.

Jason