Re: [Monotone-devel] Re: [PATCH] add xemacs and rcs merge commands to lua merge2/merge3 hooks; fix bug 8550

[Derek Scherger]

graydon hoare wrote:
> Nathaniel Smith wrote:

D'oh... I handn't meant to have the rcs merge be the default, it was at the top of my list 
so I could see how it worked.

> > How about just putting the hook in there so people can enable it if
> > they want, and also letting the merge hooks know whether they're
> > dealing with a 'merge' or an 'update'?
>
> agreed. the hook should be modified to know which sort of merge it's 
> doing (either a separate hook defined, or a boolean parameter, or a 
> string naming the merge scenario, or something). it probably shouldn't 
> call this merge-with-conflict-markers thing in cases where it'll be 
> writing back to the database immediately.

It definitely seems reasonable to not jam a file with conflict markers back into the 
database. I'd much prefer to be able to merge multiple heads into my working copy one at a 
time and see the results before moving on to the next one and *before* they get back to 
the database.

I don't expect that the conflict marking merge would do very well at all when there are 
several heads of some file either, I bet it would make a fantastic mess. I'm also 
wondering what a merge using any visual tool would look like on a big tree with lots of 
heads. I get the (hopefully wrong) impression that I'll be stuck with merge tools popping 
up incessantly until everything is fixed and happy. Is there any graceful way to stop a 
large merge session and come back to it later?

> the hook interface for merging isn't set in stone; I'll happily 
> entertain ideas on how to make it better. I know for example some people 
> have suggested passing some metadata (certs) to the hook to make it 
> easier to create useful window titles, warning / progress messages, or 
> filenames. that's feasible too.

I was certainly wondering about the helpfulness of left/ancestor/right labels in any type 
of merge tool. Certainly file names and possibly sha1 version codes would be much better.

> otherwise the xemacs stuff looks fine. I notice KDE has a nice merge 
> resolver too, and there's a tortoise one for windows.. probably we ought 
> to sniff around for these and see if we can run them, too.

Was the message about no merge tool available what you had in mind when you logged bug 
8550 or were you thinking about something more sophisticated? My "fix" seemed rather 
simplistic to me in some ways, but in others I guess the various merge tools are defined 
by the hook so presumably it's the hooks job to say it can't find any of the tools its 
trying to use.

--
Cheers,
Derek