Strange result of forced merge

[Michal Krause]

Stuart W. Marks wrote:

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

This explanation seems to be logical and history displayed with hgk
looks similar to testing repository where I simulate this, but both
developers who made merge -f swear that they didn't use push -f and I'm
pretty sure they don't have a reason to lie to me (moreover, when we
decided to use Mercurial, I declared push -f as absolutely prohibited
command so they know what it does).

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

Unfortunately, changes made later fixed this issue: "lost" changes were
committed by developer C and other developers probably made some merges,
so ALPHA surely has just one head now. When this problem will occur
again in future, I'll try to investigate more.

Meantime I'll try to do more tests to find out if there can be some kind
of rare constallation when Mercurial can allow pushing of branches
without -f.

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