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.)
I think you should do both! :-) 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. Thus our pumpking will see a series of commits that could each probably stand on their own (though there may be some dependency ordering). And there shouldn't be any spurious or throw-away commit messages like "Oops, forgot to twiddle the frobnitz in the previous commit" Just my humble opinion, -Scott -- Jonathan Scott Duff d...@lighthouse.tamucc.edu
