Help with new GCC git workflow...

Jason Merrill jason@redhat.com
Wed Jan 15 15:37:00 GMT 2020


On 1/15/20 4:55 AM, Jonathan Wakely wrote:
> On Wed, 15 Jan 2020 at 09:49, Richard Biener <richard.guenther@gmail.com> wrote:
>>
>> On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>>
>>> On Wed, 15 Jan 2020 at 08:40, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>
>>>> On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond <esr@thyrsus.com> wrote:
>>>>>
>>>>> Peter Bergner <bergner@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



More information about the Gcc mailing list