[PATCH RFC] update: add an option to allow to merge local changes when crossing branches

Martin Geisler martin at geisler.net
Wed Feb 27 16:32:59 CST 2013

Angel Ezquerra <angel.ezquerra at gmail.com> writes:

> On Sat, Feb 23, 2013 at 12:24 PM, Martin Geisler <martin at geisler.net> wrote:
>> Kevin Bullock <kbullock+mercurial at ringworld.org> writes:
>>> The theoretical problem is the same, but the _usability_ problem is
>>> very different, both because of a likely larger set of conflicts
>>> (merge early and often!), and because you'd have to do something
>>> different to get back to your original state (and we'd likely have
>>> to track more state outside of history).
>> The risk of losing changes is certainly greater when they only live
>> inside .hg/merge instead of in permanent history -- 100% agreed.
>> My starting point was only that every single time I've had the
>> "sorry, I wont help you update across branches" message I "fixed" it
>> by updating twice and could continue with my work.
> I also do this somethings although in other cases I either shelve my
> changes or commit and rebase.
> It seems that having to update back to an ancestor doubles the changes
> of making an error while merging?

Yeah, there will be situations where you get to resolve conflicts when
updating to the ancestor and get the resolve the same conflicts again
when updating to your target revision.

If there two merges were done as a single merge, then you might get
fewer conflicts: Think of a case where you modify file A.txt in the
working copy. File A.txt exists in both the working copy parent and in
your target revision, but it doesn't exist in the common ancestor: two
merges will cause a conflict that you don't get if you merge directly.

I'm not sure if the reversion situation can occur.

Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130227/772470fb/attachment.pgp>

More information about the Mercurial-devel mailing list