Hi, Richard Lowe wrote: > 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)
Will do. >> [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 Excellent - just what I wanted. I notice this option is not documented in the hg book - the merge section there is a little thin in general. Many thanks Gavin
