Proposal for the transition timetable for the move to GIT
Julien '_FrnchFrgg_' RIVAUD
Sun Dec 29 11:42:00 GMT 2019
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
> 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,
More information about the Gcc