Strange result of forced merge

[Stuart W. Marks]

I'm wondering if there's a simpler explanation for this.

Developer C had committed changes in his repo. He pulled from ALPHA, adding a 
new head to his repo, thus requiring a merge. When he ran the merge command, it 
issued a message

     (branch merge, don't forget to commit)

Suppose (#1) that C did forget to commit, and suppose (#2) that he did a "push 
-f" perhaps thinking that the merge had been committed. At this point the 
changes pulled from ALPHA are still uncommitted changes in C's working copy.

C's previously committed changes would now appear on the tip of ALPHA. However, 
they would be on a branch that was rooted from the rev at which C began his 
changes. The tip of ALPHA would thus appear to have "lost" the subsequent 
changes made by developers A and B. These changes would still be in ALPHA, but 
on a different branch from the tip. But unless you go looking for them, you 
won't find them.

What happens when you run "hg heads" on ALPHA?

s'marks

Michal Krause wrote:
> 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