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
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