On 24Mar2014 09:56, Chris Angelico <ros...@gmail.com> wrote: > On Mon, Mar 24, 2014 at 1:58 AM, Albert-Jan Roskam <fo...@yahoo.com> wrote: > > One more thing (so this is not entirely a double post!). While reading > > these books I found that the authors were pretty religious about Clean > > Commits. I mean, ok, it's not a good idea to do one huge monolithic commit > > each month, but I felt they were exaggerating. But maybe I'm wrong and > > clean commits become more important when the number of collaborators get > > bigger. It's just so easy to fix something, and e.g. correct that typo in a > > docstring while you're at it. > > > > It's important even with a single editor. When you go back and look at > a commit, you should be able to read the summary and know immediately > whether a particular line in it should have been edited or not. > Combining changes into a single commit makes that harder. > > Commits are cheap. Do more of 'em rather than less.
I'm particularly fond of "hg record" (or the similar extension, "hg crecord"), which lets you commit just parts of a modified file. When I'm in a debugging branch, it gradually turns into a huge diff. "hg record" lets me commit specific parts of a diff in a single commit. Every so often I spent a little while cleaning out related changes that are going to stay so that the final diffness consists of debug statements and hacks-in-progress; much smaller. So I'll pick a file and run an "hg record that-file" and pick all the diff parts that involve, say, removing some parameter. And in goes a single commit with just that feature change. Lather, rinse, repeat for other small concrete changes. And then my "hg diff" is back to being managably readable. Cheers, -- Cameron Simpson <c...@zip.com.au> Wagner's music is better than it sounds. - Mark Twain -- https://mail.python.org/mailman/listinfo/python-list
