hgmerge.py in mainstream mercurial distribution

[Arve Knudsen]

Would it be feasible to solve the user customization concern by allowing the
Python merge script to be easily configurable (i.e., through an ini file)?
There is a reason why the Python version of the script was written in the
first place, the need for automated logic that I don't think most people
want to mess with (including platform issues ..). If people want to write
their own merge script, why not replace the stock script via the "merge"
option in hgrc?

Arve

On Dec 10, 2007 8:43 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Mon, Dec 10, 2007 at 12:52:56PM -0600, Steve Borho wrote:
> >
> > On Mon, 2007-12-10 at 14:07 +0530, dhruva wrote:
> > > Hi,
> > >  Speaking from the M$ world, would it be a better idea to have Steve's
> > > hgmerge.py in the mainstream mercurial (as an extension)? Having a
> > > python solution instead of a shell variant would be a welcome move as
> > > we on M$ need not depend on a POSIX compliant UNIX shell. I like
> > > mercurial for various reasons and one being that it is fairly self
> > > contained.
> > >  Currently, I keep pulling changes from hgmerge's repo, I could do
> > > away with that if it were part of mainstream. Do let me know if
> > > something needs to be done to have it in the main repo or any other
> > > reasons why it is not advisable to have it in main repo.
> >
> > It would be helpful if Mercurial allowed merge wrappers to be called as
> > python hooks.  I tried to add this myself a couple months ago, but it
> > was still above my python-fu at the time.
> >
> > So far as inclusion goes, I know it violates the Mercurial coding
> > practices in many places and that it's still needlessly complex in
> > others.  It would ???greatly benefit from having many more eyes applied
> to
> > it.
> >
> > I know Matt has reservations about including any merge wrappers, but he
> > can voice those concerns here himself.
>
> Sigh, I grow weary of voicing those concerns...
>
> hgmerge is a shell script so that users can easily customize it to
> their own ends. In most cases, it boils down to a one-liner,
> rearranging command line arguments for the real merge program:
>
>  kdiff3 --auto "$BASE" "$LOCAL" "$OTHER"
>
> If someone asks "how do I handle merging JPEGs?" I say, "just hack
> your merge script to run the GIMP when the file ends in .jpg" and they
> say "oh duh, sure" and are happy.
>
> Now that it's grown into a 200-line shell script, people are too
> intimidated to hack on it, even though it's not actually doing
> anything interesting. It's 200 times more complicated than it needs to
> be.
>
> If we turn it into a Python script, I'm sure it will rapidly grow much
> larger (look, it's already 845 lines!) and all the people who would
> have been perfectly happy customizing a one-line script will now be
> asking for new features from hgmerge.py. When their requested features
> are too ugly for us to merge ("you want to merge JPEGS??!"), they'll
> decide they're screwed and go away.
>
> But then, some clever user will come along and propose that we add an
> option to call out to a simple shell script and the cycle will repeat!
>
> This isn't progress.
>
> --
> Mathematics is the supreme nostalgia of our time.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial-devel/attachments/20071210/2198f7f8/attachment.htm