This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposal for the transition timetable for the move to GIT
Le 28/12/2019 à 21:28, Segher Boessenkool a écrit :
On Sat, Dec 28, 2019 at 05:11:47PM +0000, Richard Earnshaw (lists) wrote >> I disagree. The review comments will show up as additional commits on
the branch and can be tracked back to such events. Once history gets
flattened into a major single commit it's significantly more effort to
drill down into the history and find out why if we've lost the merge
information.
Review comments should *not* correspond to any *new* commit on any
branch. At least not in the vast majority of cases. They should trigger
modifications of the existing commits.
Commits are units of meaning, and their sequence is not a timeline, but
a logical relationship (in a single patch set at least). When submitting
a feature, the different commits *should not* correspond to passing time
in the development but to incremental building of the feature. And when
a patch set is finished as in the end point is what you want, you should
rewrite it so that the changes are coherent units of change in a "small
provable steps" point of view.
Similarly that in Maths it is customary to have proofs where you first
proove a weaker result you know will be never used when you get to
proving the stronger version, if that's the cleanest/most coherent or
beautiful or convincing way to write the proof, I quite often introduce
a method or structure early in a patch set *that I know will not survive
the whole patchset and will never be in the final result*, just because
that makes the transition easier and easier to prove right, be it with
suitable passing tests, concise code changes, and extensive commit
messages that explain the reasoning (all of those are required together
IMHO).
The goad behind a patch set is to look like you wrote it linearly, with
god-like insight throughout, that enabled you to modify in small,
trivial steps some code and lead smoothly the reader towards your end
goal that is unrecognizable from the starting point. I work very hard to
attain that, because I do not have a god-like brain.
History littered with « That didn't work, now try that » or « Fix that
to make the reviewer happy » is just that, history. A VCS is not to
track history, but to track meaningful changes (IMHO again).
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.
The git project itself uses that workflow, and reading the ML is quite
enlightening (even enjoyable). Patch sets have to be rebased on the last
*release*, and every one of them gets then merged by Juno C Hamano.
That means the "first parent" history of git is only merge commits.
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.
All merges lose information. All of them. You take two branches, and
cut and paste between the two, but you never show which part is from
what, or how conflicts were resolved, etc. All this can be reconstructed
of course -- you know the inputs, and you have the output -- but the info
isn't there directly, and there is no why or what. If you're lucky there
is a mail about it, or the merge commit itself goes into it a bit.
In fact, that's one of the reasons I argue for the « always use merge
commits » rule, *even if you rebase beforehand*: the individual commits
are the logical steps, their commit message explain the local why of the
incremental changes, and the merge commit is the cover letter. It
explains the rationale of the complete set, describes the feature, etc.
Again, have a look at the git ML to see what I consider as near-perfect
application of these principles. And that can be done even without
hugely branchy repositories (look at the git repo in gitk and cringe).
I would add that of course, no merge commit should be non-trivial. If
you had to introduce code changes *in* the merge commit itself,
something is wrong. Rebase before merging (but keep the merge commit,
using the --no-ff flag).
Julien "_FrnchFrgg_" Rivaud