Gavin Maltby <Gavin.Maltby at Sun.COM> writes: > Hi, > > I've been surprised to find that 'hg merge' does not start a manual > merge (via gypfm, filemerge, or whatever your .gfrc selects) > for *every* file that is in conflict (i.e., has a status change > in both branches). It appears to believe the > differences are simple enough (I think defined as "no overlapping > or adjacent edits) that it will do the merge for me; > not surprisingly, this can go badly wrong. > > Based on ON devleopers' past experience with Teamware I think there > is a very substantial opportunity for mismerge here, i.e. folks > with habits formed under Teamware would be forgiven for thinking > all conflicts are resolved once they have handled everything > 'hg merge' pops up. I just "completed" an hg merge where 30 files > are in conflict (changed in both branches) but only 13 popped > up for interative merge while the remainder were rather > silently automerged - in around 8000 lines of change it would be > quite possible to miss resulting errors. Fortunately I had manually > generated a report on all files common to each branch and am > keeping notes on merge actions on each file.
Please file a bug suggesting we adjust hgsetup(1) to create an .hgrc that prevents this. (consolidation/os-net-tools) > [merge-tools] > filemerge.gui=True > filemerge.executable = /opt/teamware/bin/filemerge > filemerge.args=-a $base $local $other $output > filemerge.checkchanged = true Add: filemerge.premerge = false To the above section, and it should stop doing that. -- Rich
