in reply to Re: Reading Someone's Program
in thread Reading Someone's Program

A good rule of thumb for the "often" part of local committing is:
you've changed something and managed to get it to compile again -> commit!

Replies are listed 'Best First'.
Re^3: Reading Someone's Program
by Voronich (Hermit) on May 18, 2011 at 12:52 UTC
    "managed to get it to compile again" o.O? I'm going to assume you mean "have added thorough tests for the changed code and confirmed they all pass".
    Me
[reply]

      No, that would be the commit following :)

      I really don't like having the (small) fix in the same commit as the commit that adds a number of tests to verify the fix. Note that the OP is dealing with a project that does not have tests (yet).

      In a project where you do test-driven development, I would completely agree with you.


      Enjoy, Have FUN! H.Merijn
[reply]

        heh. My comment was more about the "compiling is unit testing" philosophy. Plus I've become a bit of a TDD crack monkey.

        Though it reminds me of something that's come up for me a few times. I've lately been finding myself wanting to have a local subordinate source control repository (more like a sub-branch.) That way intermediate nonfunctional code versions would be checked in at save time, but not committed to the real branch.

        I'm not at all convinced it's not a wrongheaded thought. But I'm frequently finding myself wanting to roll back micro-changes that weren't solid enough to check in to the primary SCM system.

        Me
[reply]

In Section Seekers of Perl Wisdom