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.
Of course these are only snippets from two threads, but the underlying idea here seems to be that some reviewers prefer large branches of code that can be reviewed all at once rather than a lot of small commits. And some committers similarly prefer a "touch it once" approach (particularly if there are several bugs related to the same area of code) over a bunch of commits, for a variety of reasons, some of which are related to the annoyance of Gerrit (Git?) dependency linking and others of which are related to varying ideas of what's most efficient/easiest/sanest.
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?
MZMcBride