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
