On Jan 17, 2013, at 11:53 PM, Benny Malengier <benny.malengier@gmail.com> wrote:

Is this because you use git?

If so, it would be interesting that you use a devel branch, use git squash to combine the commits in master (http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash ), and use the single commit then for push to subversion. That would make it easier for the subversion users as wel as for code review.


Yes, that's what I did (though with git rebase -i, not git merge -- git merge and git-svn don't get along at all). I cut about 50 commits down to 8 or 9 (the others are fixes to pre-existing bugs that I made along the way) to present a progression of related changes. This way the commit messages can explain what's going on in each changeset (rename files, replace module x, etc.) rather than having a single massive changeset that does a dozen things at once, and no way to separate which bits of the changeset implement what changes. It might complicate code review if you do it one changeset at a time, because (as in the instant case) you think of an improvement in one only to find that I did exactly that two changesets later, but if you're examining a file down the road and trying to understand what it does and why it's implemented the way it is, having an understandable history makes the task much easier.

John Ralls