[PATCH 1 of 4] hgmerge: add new hgmerge package under mercurial

[Matt Mackall]

On Tue, 2008-01-08 at 12:59 -0600, Steve Borho wrote:
> On Tue, 2008-01-08 at 11:49 -0600, Matt Mackall wrote:
> > 
> > 
> > > +def _is_mergeable(base, local, other):
> > > +    ''' Are the files mergeable?
> > > +    @return: Success?
> > > +    '''
> > > +    mergetypes = ('dos', 'unix', 'mac')
> > > +
> > > +    for eoltp in (local.eoltype, other.eoltype, base.eoltype):
> > > +        if eoltp not in mergetypes:
> > > +            return False
> > 
> > Hmmm. Don't really like this. Does it apply to user-defined tools?
> 
> I should have responded to this as well, since this was my code.
> 
> This routine is checked before all merges, unless the merge tool was
> specified by a file filter.
> 
> None of the 3-way merge tools I tested could do anything sane with
> symlinks or binary files.  They all had failure modes somewhere between
> annoying and disasterous (simplemerge itself will backtrace on some
> symlinks).  So hgmerge tried to catch those cases before invoking any
> textual merge application.
> 
> For the file extension based tool selections, it assumes that the file
> is likely to be binary so it bypasses the is_mergeable and simplemerge
> steps entirely and just runs the specified tool.

That's probably a fair assumption.

> I'm open for discussion on how implicit or explicit these checks needs
> to be.  For instance, even merge tools that properly handle binary files
> would probably get tripped up by symlinks.

We probably want:

tool.binary = True # default False, unless pattern matches
tool.symlink = True # default False, even when pattern matches

-- 
Mathematics is the supreme nostalgia of our time.