[issue1038] Hook to reject catastrophic merges
mercurial-bugs at selenic.com
Mon Mar 17 14:58:23 CDT 2008
New submission from Jesse Glick <jesse.glick at sun.com>:
Since there is no apparent easy way to fix a completely wrong merge (generally
one which accidentally reverted other work) - see Issue1010 - and it is hard to
even notice such merges in a big team - see Issue981 - and the Hg UI is such
that it makes them likely - see Issue28, Issue1011 - it would be very valuable
to able to reject such merges before they can be pushed to the server and cause
1. When receiving a merge changeset, simulate doing the merge of the two
parents. Note any textual merge conflicts (not just quiet successful merges of
noninterfering changes in the same file), as well as miscellaneous conflicts
(e.g. edited but deleted, renamed twice differently).
2. Collect the diff from the actual merge changeset to the simulated merge.
Discard any diff entries for files which were actually in conflict as previous
3. If the discrepancy is too large - say, expressed as a percentage of the sum
of the sizes of the diffs to each merge parent - assume the merge is bad and fail.
There is a risk of false positives coming from someone doing a genuinely
complicated merge of semantically conflicting changes. But in this case you can
probably do a quick merge first, resolving any textual conflicts and committing,
then going back and checking for semantic conflicts: making sure all files
compile, tests pass, ad nauseam. This is perhaps easier to understand in later
history later anyway (in the absence of Issue981).
There probably needs to be an override mechanism for experts to push a merge
which intentionally does something unusual, such as "capping" a dead branch, or
in fact recovering from an older bad merge.
Sample bad merge which would be rejected:
nosy: bos, jglick, mzlamal
title: Hook to reject catastrophic merges
Mercurial issue tracker <mercurial-bugs at selenic.com>
More information about the Mercurial-devel