On 09/04/2012 07:38 PM, MZMcBride wrote:
Antoine Musso wrote:
Le 29/08/12 23:55, Sumana Harihareswara wrote:
- 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. --> http://nuclearsquid.com/writings/git-add/
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 on context?
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?
Mark.