Question about Source Control

[Cameron Simpson]

On 24Mar2014 09:56, Chris Angelico <rosuav at gmail.com> wrote:
> On Mon, Mar 24, 2014 at 1:58 AM, Albert-Jan Roskam <fomcl at 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 <cs at zip.com.au>

Wagner's music is better than it sounds.        - Mark Twain