I have found that Hg lets you commit a specific file or dir list from a merge
working copy (i.e. with two parents), without printing any kind of warning. This
is a really bad idea because a novice user could do something like this:
$ hg clone ...
$ # edit myfile
$ hg di
--- myfile
+++ myfile
....
$ hg ci -m 'edited my file'
$ hg push
there are remote changes, merge
$ hg fetch
merging myfile...
# merge tool pops up on myfile, user closes
318 files updates, 1 files merged, 22 files removed, 0 files unresolved
don't forget to commit
$ hg ci -m 'merged' myfile
$ hg push
there are remote changes, merge
$ hg fetch
there are local changes!
$ hg up -C
...
$ hg fetch
...OK...
$ hg push
and effectively revert everyone else's work.
(I have documented evidence of someone at least doing the commit on a particular
file, though in this case rather than using up -C he committed the remaining
files as a separate non-merge changeset, so the end result luckily did not lose
any changes. I suspect that known cases of bad merges which did lose work were
the result of people following something like the sequence above.)
IMHO Mercurial should not permit a commit of a specific file or dir list to
proceed when that would create a merge changeset, as the resulting changeset
would not accurately reflect the true merge of its parents. (Perhaps there could
be a --force option to override this check.) If you really wanted to discard
some changes from one of the parents, you can always run 'hg revert'.
|