On 09/04/2012 07:38 PM, MZMcBride wrote:
Antoine Musso wrote:
Le 29/08/12 23:55, Sumana Harihareswara wrote:
1) Write small commits.
I cant stress how important this is. git has several ways to split a commit:
- git rebase --interactive <parent commit sha1>
- reset to master and git cherry-pick --no-commit <sha1> then use git
add --patch to select the hunk to craft a new small commit.
In a previous wikitech-l thread from April 2012, Tim Starling wrote:
Larger things with more benefits tend to get a
higher priority than
smaller things. So it's usually quicker to get 1500 lines of code
reviewed than 15.
This seems to be a nasty discrepancy.
I think some kind of reconciliation is needed here in
the advice to
committers, new and old. I guess whether to split commits up or not depends
Or maybe these simply the differences in the sorts of reviews that
people like to do? Or maybe its a bit of both?
"If this is a major change you really want Tim to review, then make a
single big commit. If you want Krinkle to review your code, don't batch
it up into several seemingly unrelated changes in a big blob."
Because Sumana's initial instructions weren't about any particular
developer, maybe this is just something she has noticed as a tendency?