Re: Proposal for the transition timetable for the move to GIT

[Julien '_FrnchFrgg_' RIVAUD <frnchfrgg@free.fr>]

Le 29/12/2019 à 11:41, Segher Boessenkool a écrit :
> On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote:
>>> Oh, I'm not talking about historical merges.  I'm saying we shouldn't do
>>> future merges, where we can help that.  It disagrees with our documented
>>> "submitting patches" protocol.
>> I don't see how that can be correct. Linux is heavily "submitting
>> patches" based, with stringent reviews on LKML, yet heavily uses merges.
> Linux has most development done in separate trees, one for each maintainer.
> That is not how GCC works.

I mentioned the git development for a reason. They use merges for 
*everything*, including patchsets by people who never contributed before 
and might never contribute afterwards. The very *concept* of a DVCS is 
that each developer has a separate tree, not each maintainer.

I'm not arguing that you should go that route, it seems a bit extreme to 
me. But outright refusing merges on the basis they are painful is (if 
you can accept the strong word) ludicrous.

> Nothing should ever be flattened to a single commit. But before patches
>>> hit trunk, the patch series can be made nicer than it was at the start
>>> of its development.
>> I quite agree with that, and it resonates with my TL;DR chunk of text above.
> Yup.  Rebasing is superior to merging in many ways.

That's not what I agreed with. I agreed with « the patch series can be 
made nicer », which I took to be the contrary of « append patches at the 
end ». Rebasing is *one* of the ways to do that, especially interactive 
rebasing to shuffle patches around, check that each step compiles and 
passes the full test suite (updating it if needed and correct), reword 
messages, and think a lot of times about the best progression. But I 
never opposed rebasing to merging. In particular, I clearly wrote that 
*even if you rebased*, there are very strong arguments out there about 
refusing fast-forward merges, that is *always* generate a real merge 
commit, with a cover letter message roughly corresponding to the mail 
people send on the ML to convince people their patch series are worth 
including in GCC.

That leaves individual commit messages to explain the local rationale 
behind each discrete change (not the how, as it is readily apparent from 
the code, unless the code is very clever and then an in-code comment is 
warranted)


> Merging is appropriate if there is parallel development of (mostly) independent things.

Which is almost always the case.

> Features aren't that, usually: they can be rebased easily, and they should be posted
> for review anyway.
How often successive features checked into GCC are dependent on each 
other ? The fact that they can be rebased either way and easily is 
almost a testimony of that. And the fact that they need review has 
nothing to do with anything.
> It is very easy to use merges more often than is useful, and it hurts.

And it is very easy to use SVN-like workflows, and it hurts far more. 
SVN, due to its centrality and inherent impossibility to encode logical 
relationships between changes (as opposed to time-based evolution), 
slowly impaired most developers mind openness about what can be done in 
a worthwhile VCS. Moving to git is an opportunity to at last free 
yourselves, not continue that narrow treading on SVN paths.

SVN was like an almanac listing successive events without any analysis. 
That's not History (as in the field of study). Git at least can let you 
express and use to your common benefit logical links between 
modifications. Don't miss that train.

Merges are not scary when the tools are good. Even the logs are totally 
usable with a lot of merges, with suitable tools. The tool has to adapt, 
not you.

Julien