Handling changed/deleted conflicts with non-interactive terminals

[Thomas Arendsen Hein]

* Angel Ezquerra <angel.ezquerra at gmail.com> [20131001 09:20]:
> On Tue, Oct 1, 2013 at 5:57 AM, Siddharth Agarwal <sid0 at fb.com> wrote:
> > One issue that's popped up here recently is handling changed/deleted
> > conflicts (cdcs for short) during merges, when the terminal is
> > non-interactive. cdcs occur when the file to be merged is changed on one
> > side and deleted on the other.
> >
> > Currently (in merge.py:manifestmerge) we always choose the default option,
> > which is to keep the changed file. That's reasonably sensible, but there's
> > no way for the process that's using hg non-interactively to figure that out,
> > short of grepping for the string in hg's output. There's also no indication
> > that something's gone wrong, nor a non-zero exit code.
> >
> > Our use case is an automatic rebase-and-push done on a server -- it needs to
> > fail and go back and ask the user to manually rebase in the c/d case. We've
> > currently worked around it by grepping output, but it would be great to have
> > a non-hacky solution for this.
> >
> > mpm and I worked out a tentative solution today, which goes something like:
> > - for non-interactive terminals, treat cdcs as unresolved
> > - add a new status to the persistent merge state, for cdcs
> > - hg resolve <cdc path> shows the current prompt: either local changed
> > remote deleted or local deleted remote changed.
> > - hg resolve --mark <cdc path> keeps the changed version
> > - hg rm <cdc path> && hg resolve --mark <cdc path> deletes the file
> >
> > For backwards compatibility, we'll need to store the extra statuses in a
> > separate file so that older hg won't barf at it. Figuring out when and how
> > to invalidate that file is somewhat tricky.
> >
> > Does the general idea make sense? Is there anything we're missing here that
> > should be added?
> >
> > mpm mentioned that this would be useful to TortoiseHg as well, so ccing
> > Steve Borho.
> 
> I think this good be nice, and as you say it would be useful to TortoiseHg.
> 
> Perhaps it would also make sense to do this for other sorts of merge
> prompts, such as subrepo path change conflict prompts (and the
> recently introduced subrepo merge/local/other selection prompts)?

The branch "project2009" in
http://hg.intevation.org/mercurial/tah-project2009/
contains an implementation for this, but it is based on an older
version of Mercurial and was intended to work as an extension that
monkey-patches the relevant function, so it is not integrated very
well. The directory hgext/project2009 contains copies of merge.py
and copies.py which are patched into an existing installation with
the code in __init__.py

It allows configuring external prompt-tools similar to the current
mechanism of configuring external merge tools.

See
http://selenic.com/pipermail/mercurial-devel/2012-July/042966.html
for some discussion about this.

It would be nice to have this integrated into the main Mercurial code.

Regards,
Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner