Re: [Bf-committers] Commit overload
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 mie...@gmail.com wrote: Shouldn't arc land take care of squashing the patches? Or is this outside phabricator? On Fri, Jan 3, 2014 at 3:54 PM, Campbell Barton ideasma...@gmail.com wrote: Many small commits are fine IMHO if each one is doing some change which stands on its own, If they include edits on previous commits from the same patch-set, this ends up being noise in our history and I'd rather see them squashed. eg: 53ef7a9932e974ee3efb5e63b3757051c14f6635 but there were only 1-2 of these. On Sat, Jan 4, 2014 at 9:26 AM, Jonathan Williamson jonat...@cgcookie.comwrote: Ah great tip with --squash Dalai. Thanks! I was just learning about rebase -i, which is also very useful. Jonathan Williamson http://cgcookie.com On Fri, Jan 3, 2014 at 4:22 PM, Dalai Felinto dfeli...@gmail.com wrote: You can do git merge --squash next time, that will make one commit out of all the individual ones. Or git rebase -i HEAD~3 (or 10, ...) to group commits together) It's really a matter of deciding how relevant the individual logs are for our git history. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014/1/3 Jonathan Williamson jonat...@cgcookie.com: Sorry about the commit overload just now. Will apply patches directly to master instead of merging in the branch next time :) Jonathan Williamson http://cgcookie.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commit overload
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 mie...@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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Commit overload
Sorry about the commit overload just now. Will apply patches directly to master instead of merging in the branch next time :) Jonathan Williamson http://cgcookie.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commit overload
You can do git merge --squash next time, that will make one commit out of all the individual ones. Or git rebase -i HEAD~3 (or 10, ...) to group commits together) It's really a matter of deciding how relevant the individual logs are for our git history. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014/1/3 Jonathan Williamson jonat...@cgcookie.com: Sorry about the commit overload just now. Will apply patches directly to master instead of merging in the branch next time :) Jonathan Williamson http://cgcookie.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commit overload
For me I would say that if the commits have well separated additions then it's OK, even if there's a flood. There's also git rebase -i that allows you to squash commits together if you haven't pushed them yet. I use it all the time for local branches since I can commit often so as not to lose any work and squash the commits later for nice trunk push. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commit overload
Ah great tip with --squash Dalai. Thanks! I was just learning about rebase -i, which is also very useful. Jonathan Williamson http://cgcookie.com On Fri, Jan 3, 2014 at 4:22 PM, Dalai Felinto dfeli...@gmail.com wrote: You can do git merge --squash next time, that will make one commit out of all the individual ones. Or git rebase -i HEAD~3 (or 10, ...) to group commits together) It's really a matter of deciding how relevant the individual logs are for our git history. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014/1/3 Jonathan Williamson jonat...@cgcookie.com: Sorry about the commit overload just now. Will apply patches directly to master instead of merging in the branch next time :) Jonathan Williamson http://cgcookie.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commit overload
Many small commits are fine IMHO if each one is doing some change which stands on its own, If they include edits on previous commits from the same patch-set, this ends up being noise in our history and I'd rather see them squashed. eg: 53ef7a9932e974ee3efb5e63b3757051c14f6635 but there were only 1-2 of these. On Sat, Jan 4, 2014 at 9:26 AM, Jonathan Williamson jonat...@cgcookie.comwrote: Ah great tip with --squash Dalai. Thanks! I was just learning about rebase -i, which is also very useful. Jonathan Williamson http://cgcookie.com On Fri, Jan 3, 2014 at 4:22 PM, Dalai Felinto dfeli...@gmail.com wrote: You can do git merge --squash next time, that will make one commit out of all the individual ones. Or git rebase -i HEAD~3 (or 10, ...) to group commits together) It's really a matter of deciding how relevant the individual logs are for our git history. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014/1/3 Jonathan Williamson jonat...@cgcookie.com: Sorry about the commit overload just now. Will apply patches directly to master instead of merging in the branch next time :) Jonathan Williamson http://cgcookie.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commit overload
Shouldn't arc land take care of squashing the patches? Or is this outside phabricator? On Fri, Jan 3, 2014 at 3:54 PM, Campbell Barton ideasma...@gmail.comwrote: Many small commits are fine IMHO if each one is doing some change which stands on its own, If they include edits on previous commits from the same patch-set, this ends up being noise in our history and I'd rather see them squashed. eg: 53ef7a9932e974ee3efb5e63b3757051c14f6635 but there were only 1-2 of these. On Sat, Jan 4, 2014 at 9:26 AM, Jonathan Williamson jonat...@cgcookie.comwrote: Ah great tip with --squash Dalai. Thanks! I was just learning about rebase -i, which is also very useful. Jonathan Williamson http://cgcookie.com On Fri, Jan 3, 2014 at 4:22 PM, Dalai Felinto dfeli...@gmail.com wrote: You can do git merge --squash next time, that will make one commit out of all the individual ones. Or git rebase -i HEAD~3 (or 10, ...) to group commits together) It's really a matter of deciding how relevant the individual logs are for our git history. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014/1/3 Jonathan Williamson jonat...@cgcookie.com: Sorry about the commit overload just now. Will apply patches directly to master instead of merging in the branch next time :) Jonathan Williamson http://cgcookie.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
