[PATCH 4 of 8 RFC] update: when guarding, check merges for conflicts

Matt Mackall mpm at selenic.com
Wed Dec 21 16:30:54 CST 2011


On Wed, 2011-12-21 at 23:25 +0100, Laurens Holst wrote:
> Op 21-12-2011 22:15, Matt Mackall schreef:
> > On Wed, 2011-12-21 at 20:45 +0100, Laurens Holst wrote:
> >> # HG changeset patch
> >> # User Laurens Holst<laurens.hg at grauw.nl>
> >> # Date 1324433649 -3600
> >> # Node ID 64831bdb5dddf916d5378ace8965a2b2d619d5ee
> >> # Parent  0fe9df236d957abc682c75d71910fa041c7390fd
> >> update: when guarding, check merges for conflicts
> >>
> >> If a file is changed both in the working copy and in one of the updated
> >> changesets, during the guarding phase it will attempt to merge the two using
> >> simplemerge to see if there are conflicts. If none of the mutually changed files
> >> have conflicts, the guard will allow the update to proceed.
> >>
> >> diff -r 0fe9df236d95 -r 64831bdb5ddd mercurial/merge.py
> >> --- a/mercurial/merge.py	Wed Dec 21 04:04:52 2011 +0100
> >> +++ b/mercurial/merge.py	Wed Dec 21 03:14:09 2011 +0100
> > [...]
> >> +            # test-merge mutually modified files to see if there are conflicts
> >> +            m3 = simplemerge.Merge3Text(fca.data(), fcl.data(), fco.data())
> > Big layering violation here. The merge tool configured for the given
> > file may deal with this perfectly, or refuse to work at all.
> >
> 
> Mmm yes there is an assumption that a merge tool essentially merges 
> equally smart or smarter. I wrote a comment about that in the commit 
> message of patch 8.

No, the problem is bigger than that. "Layer violation" means "you have
no business even trying to do this here".

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list