Feature Request: improve merging of .hgsub

Chad Dombrova chadrik at gmail.com
Tue Aug 10 13:19:34 CDT 2010


On Tue, Aug 10, 2010 at 9:59 AM, Matt Mackall <mpm at selenic.com> wrote:

> On Tue, 2010-08-10 at 09:33 -0700, Chad Dombrova wrote:
> > if mercurial tracked the list of controlled files the way it tracks
> > subrepos, as a simple text file that was merged like any other,
> > mercurial users would give up in frustration.
>
> Yes, let's be melodramatic.
>

 i apologize for the dramatic phrasing, but if you stop and picture it --
users manually merging the list of files tracked by mercurial -- i think
you'll agree that it would be frustrating.


> We assume that users know how to edit and merge simple text files.
> Otherwise, they're going to have a really hard time using Mercurial
> anyway.
>

true enough.

Automatic merging of .hgsub only breaks right now when a) two people
> modify it 'simultaneously' and b) they do it in a way that conflicts.
> Making a custom merger for .hgsub will only slightly narrow the set of
> cases that conflict (mostly by taking line ordering out of the picture).
>

line ordering and line formatting.  at the moment, i don't think most users
realize that .hgsub can utilize the full config syntax, so there's little
variation in the file, but if .hgsub becomes a full-fledged rc file in the
future, then conflicts will be much more likely.  imagine trying to merge
hgrc files.

So you've only slightly improved some cases and moved from an occasional
> clunky text file merge to what's effectively our only other option: an
> less frequent but considerably more clunky set of interactive prompts
>

i don't think there would be any more need for interactive prompts than
there is now.  hg would merge .hgsub using its custom method, and if it
found conflicts, default to text merging.


> (and a bunch of ugly new code and tests and bugs to go with it). I'm
> afraid I don't see that as an improvement.


i understand your desire to avoid special cases.  from my perspective it's
worth the added code for the ease-of-use, but obviously if i can't convince
you of that then things aren't going anywhere.

-chad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100810/28e2ccb2/attachment.htm>


More information about the Mercurial-devel mailing list