Re^4: Reading Someone's Program

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

Comment on Re^4: Reading Someone's Program

Replies are listed 'Best First'.
Re^5: Reading Someone's Program by Voronich (Hermit) on May 18, 2011 at 14:58 UTC
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]
Re^6: Reading Someone's Program by John M. Dlugosz (Monsignor) on May 20, 2011 at 20:22 UTC
For sure. I've become a fan of git and several people at my last $dayjob have continued using it for that purpose even after some other SCM was introduced by $boss. I think it works great as a fancy personal "undo" and log for minute-by-minute changes. You can manipulate deltas using it, and find more uses as a general purpose tool than just a repository. It's trivial to start filing stuff in it: just `git init` in that directory. Oh, Perl itself has moved to git.	[reply] [d/l]
Re^6: Reading Someone's Program by eclpmb (Hermit) on May 19, 2011 at 10:29 UTC
That pretty much is how Distributed Version Control works, you have your own repository to check things into, and when it's ready for wider exposure you push your changeset to the upstream change set.	[reply]