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 <[email protected]> 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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
