On Tue, Mar 10, 2009 at 09:02:08AM -0500, Jonathan Scott Duff wrote: > On Tue, Mar 10, 2009 at 08:40:12AM -0000, Rafael Garcia-Suarez wrote: > > Moritz Lenz wrote in perl.perl6.compiler : > > > Hi, > > > > > > fREW Schmidt wrote: > > >> I just threw together a workflow for git with rakudo ( > > >> http://wiki.github.com/rakudo/rakudo/frews-recommended-workflow) and I > > >> think > > >> it will help a lot. Hopefully I didn't make any mistakes. Anyway, I > > >> plan > > >> on trying it out tomorrow (Boo Haman!) and I'd appreciate it if anyone > > >> who > > >> knows git well will make any necesary changes. > > > > > > When you did more than one commit in the branch, please merge with the > > > ---squash option, so that our dear pumpking only has to review one > > > patch, not multiple. > > > > As someone who reviews patches quite often, my advice would be exactly > > the contrary -- I tend to prefer a series of small patches with long > > commit messages: that way it's easier to review the logic of the whole > > change. (Personal taste only.)
Our initial attempts in this regard didn't work well -- submissions would contain individual commits that contained lots of false starts and backtracks, making it hard to see the result. > When you're committing false starts and partial implementations, you > should use rebase -i and squash those commits into a single > complete-feature commit (and thus a single patch). > > If, ultimately, the subject of your branch has several pieces or takes > several steps to fully implement, each of those steps should be a > commit of their own. Exactly. Pm
