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

[Laurens Holst]

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. I think I should do this only if the tool has the 
premerge flag set (in which case the above holds), and just abort 
otherwise. That is the behaviour of the changes up to this patch, and to 
be honest that already goes a long way in achieving what I want.

p.s. I realise there is some room for refactoring by the way, some of 
the logic here and in later patches I copied from some place else. 
However the current merge code includes maintaining a mergestate and 
writing (temporary) files to disk, stuff that I didn’t want to deal 
with. I should probably pull certain things into a helper function or two.

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Working @ www.roughcookie.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4332 bytes
Desc: S/MIME cryptografische ondertekening
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111221/d1cacbe2/attachment.bin>