Strange result of forced merge

[Michal Krause]

Matt Mackall wrote:

>> we use Mercurial for development of midsize projects in team of 6 
>> developers. Two times one developer used hg merge -f (because he
>> had outstanding uncommitted changes) and result of this operation
>> was that all changes made by other developers between both heads
>> were completely lost in repository, but they all appear in
>> developer's working copy as uncommitted.
> 
> I'm not sure what you're describing here but I suspect something else
> is happening.

OK, I'll try to describe it on model situation:

Developers A, B and C starts development with the same copy of central 
repository (called ALPHA).

Developer A made one commit (lets call this changeset A1) and pushed it
into ALPHA repository. Than developer B made another commit (B1), pulled
A1 from ALPHA, performed hg merge (without -f), committed result of 
merge and pushed all changes into ALPHA. At this moment, ALPHA log look 
something like this:

tip - branch merge of A1 and B1
A1
B1
...

Meantime developer C made some changes in his working copy. Some of them
were committed (changeset C1) and some not. Than he pulled changes from
ALPHA, so merge was needed, but due to uncommitted changes, merge with 
-f was used. Unfortunately, I'm not sure, if merge was committed and 
pushed immediately at this point :( All three developers than continued 
in their normal work but later they realized, that all changes from 
changesets A1 and B1 were lost (i.e. file content was reverted to state 
before A1 changeset, newly added files disappeared and removed files 
came back). But than they found all these changes from changesets A1 and 
B1 in working copy of developer C as uncommitted.

The problem is that my colleagues realized it after hour or two of
work, so I was unable to detect what exactly happened. In contrast to
described model situation, our team has six developers and much more
than three changesets were affected by this problem because of very
active development. Moreover, I cannot get similar result in simulated
environment.

It's possible that we made some terrible mistake, but I cannot find
where. But I'm pretty sure that in both cases when we got into this
situation, some of developers used hg merge -f. So I'm asking here and I
hope that it will help us to avoid this problem in future.

> Perhaps it's a problem with his environment. Does his merge tool work
> correctly?

There were no conflicts so no external merge tool were used - only hg
merge -f was called.

>> By the way, is there a chance that Mercurial will allow merging
>> with uncommitted changes if they don't conflict with both heads
>> being merged?
> 
> Merge -f should work as expected. It's just a bad idea as it records 
> two steps as one.

What do you mean with two steps it records? Are you talking about next
commit which will record uncommitted changes and result of merge at 
once? I think that Mercurial can help users to solve this problem. 
Forced merge can commit merge result if it doesn't interfere with 
uncommitted changes for example. I think that it should be safer than if 
developer tries to commit merge manually and should generate more 
readable history because it prevents users from committing merge with 
other changes as one changeset.

Maybe I'll try to write extension which can make merging with 
uncommitted changes easier for developers. So, can I consider following 
steps as safe (i.e. they shouldn't corrupt or lost anything)?

1) retrieve list of uncommitted files (UNCOMMITTED FILES)
2) retrieve list of files modified in both heads (MERGE FILES)
3) if there are no files listed in both lists at once, merge heads
4) commit files from MERGE FILES list

Best regards
-- 
Michal Krause
Internet Info, s.r.o.