Uncommitted changes and merge

[Peter Arrenbrecht]

On 9/6/07, Patrick Mézard <pmezard at gmail.com> wrote:
> <short-unoriginal-digression>
> I have come to think the ability to split development tasks in
> self-sufficient, releasable steps expressing a logical progression to
> the goal, and capturing this progression correctly with source control
> tools is a skill as important as any other usually emphasized when
> teaching CS. This practice makes the resulting code cleaner, improves
> changes reversibility, shows the developer actually understands what he
> is doing, and enable code reviews.
> Doing code reviews is a good way to becoming aware of the development
> process (rather than focusing on the development result), and improving
> coding habits.
> </sorry-for-the-noise-really-i-did-not-indend-to-be-patronizing-here>

I fully agree. Which is why I - and, I wager, Lars too - care about
this issue at all. But the point is, I quite often realize a little
too late that I have, in fact, mixed things. Mostly this happens with
small code cleanups that come like a reflex.
-peo