[Bf-committers] Commit overload

[Julien RIVAUD (_FrnchFrgg_)]

Le 05/01/2014 13:13, Sergey Sharybin a écrit :

> Keir, that were direct commits, not arc ones by the all looks of them.
> Requiring everyone to use arc is a bit too much at this stage ;)
>
> On Sat, Jan 4, 2014 at 5:58 AM, Keir Mierle <mierle at gmail.com> wrote:
>
>> Shouldn't arc land take care of squashing the patches? Or is this outside
>> phabricator?

For what it's worth, I don't think that arc's policy of squashing patch 
series is good. It encourages bad commit workflow with humongous 
commits. You'll curse it when a git bisect tells you the bug has been 
introduced by the 1000-lines commit, instead of getting a nice 5-line 
change to blame...

And I must again insist on the benefits of integrating patch series into 
trunk with a merge commit (as long as the series have more than 2 commits).

The merge commit gets a message about the intent of the series, kind of 
the message you give in a pull request or the "cover letter" of a patch 
sent by mail. Individual commits then only describe why the specific 
change is done without necessarily explaining over and over again the 
big picture.

You get better log messages, easier reverting of a whole patch set, and 
clearer distinction between commits belonging to different series. And 
probably more benefits that I forget.

Understand me well: patch sets still should be rebased to current trunk 
before integration, but the integration should be done by "git merge 
--no-ff".

Maybe that's too soon for that workflow, but waiting isn't going to make 
devs anymore ready IMHO, and I see more and more cases of "this feature 
has been developped in a branch, but instead of using rebase -i to 
extract a clean path set with small individual commits out of it, lets 
commit a huge clump of code à la SVN". I think that's detrimental to the 
code quality in the end. With SVN it was hard to do otherwise, but the 
whole point of changing tools was to enable healthier version control 
habits, right ?

This "lets avoid merges at all costs" policy eludes me.

Cheers, and happy new year.

Julien "_FrnchFrgg_" Rivaud