Uncommitted changes and merge

[Patrick Mézard]

Peter Arrenbrecht a écrit :
>> Yes.
> 
> That was a bit short. Care to elaborate? I have the same woes as Lars,
> and so far mq has not solved my problems. In particular, it seems to
> not handle binary files.

It does if you use --git patches.

> And I think it is difficult to untangle a bunch of changes into
> disparate patches after the fact. So when you get carried away
> changing unrelated stuff, mq does not help, I think.

I think it can be solved by development practices. When you edit code 
you have to know where you are going and usually, if you know the 
codebase well enough, you almost know how the end result will break down 
into patches. Now if you start editing unexpected stuff it mean this is 
time to reassess the scope of the current task. When this happen, I 
shelve the current changes into an unfinished patch, pop it and start 
implementing the emerging dependencies first. When done, I try to push 
back my initial intent, which may need some surgery or not to apply 
cleanly again, depending on my initial oversight.

<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>

Besides, merge changesets are not bad, especially when they carry no 
*real* conflicts. Sure committing often is good. But it does not mean 
you have to commit on top of other people changes every time, just that 
your commits should make it to the reference repository quickly. Just do 
your work on your local branch then merge when you are ready to publish. 
Sure, the more you wait for the merge, the harder it might be. But it 
means the initial task was too large and had to be split in more 
manageable/releasable ones. Take a look at mercurial crew or crew-stable 
repositories, maybe 1 revision out of 5 is a merge changeset (OK, most 
of them come from pulling crew-stable in crew but still merges are not 
ugly).

--
Patrick Mézard