Strange result of forced merge

[Shane Holloway]

Hey Michal,

I don't have comments on the technical way merge -f is working, but I  
do have a few experiences similar to the one you have described.  We  
have had a few times where changes were mysteriously lost due to the  
merge tool we were using, and a few times that a developer used merge  
-f when he should not have committed and merged instead.

Our developer was thinking that he would just update to "the latest"  
from another developer.  He was mid-change, but didn't really think  
anything of it.  I think he wanted to have it save his changes, merge  
the parent and the new head, and then reapply his changes.  (This can  
be accomplished with mq, but that is another point altogether. :)   
What I told him to do when he gets the "abort: outstanding  
uncommitted changes" message is to just finish what he's working on,  
or commit his changes, merge, and then continue finishing the  
changes.  The second option is not wonderful for the changeset  
history, but we like it better than losing changes.

So, in conclusion, we adjusted the way we work to mercurial's model.

Thanks,
-Shane Holloway


On Mar 23, 2007, at 3:59 AM, Michal Krause wrote:

> Hello,
>
> 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 know that merge -f is potentially dangerous operation and it  
> probably should not be used, but I'd like to know what can be the  
> real cause of such result of merging, because developer who made it  
> swears that he didn't made anything special and all my attempts to  
> simulate it in testing environment failed (all merges including  
> forced worked as expected).
>
> 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?
>
> Best regards
> -- 
> Michal Krause
> Internet Info, s.r.o.
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial