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

["Julien \"FrnchFrgg\" Rivaud" <frnchfrgg@free.fr>]

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