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

[Martin Geisler]

Kevin Bullock <kbullock+mercurial at ringworld.org> writes:

> On 22 Feb 2013, at 7:24 AM, Laurens Holst wrote:
>
>> I’m not entirely clear why this isn’t the default? Any update with
>> local changes is performing a merge anyway (with all its risks for
>> conflicts), so why would updating across branches need to be
>> prohibited?
>
> Much greater likelihood of conflicts, and no way to get your local
> changes back if you want to bail.

We do save the original files when merging a dirty working copy into a
target revisioon -- 'hg resolve --tool internal:local' will give them
back to you even though they were never committed anywhere.

I don't know why you say the risk of conflicts is greater here than with
any other update/merge?

> In a normal linear update with changes in the working copy, all
> Mercurial has to do is apply the changes in the working dir to the
> target head, and write the result back into the working copy.

It actually does a normal three-way merge as if you had temporarily
commited your changes and now rebase the temporary commit to the target
for your update.

> To update across branches, it would have to apply _all_ the changes
> between the common ancestor and the working copy, and write the result
> into the working copy. Thus the likelihood of clobbering uncommitted
> changes is much greater (and much more subject to operator error in
> your merge tool of choice).

I think you're saying that an update the crosses branches will tend to
"span" a greater range of revisions than an update that is linear.

That seems reasonable, but the underlying merge problem ought to be the
same as if you had done a linear update across a big span of revisions.

-- 
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/20130222/0a42342b/attachment.pgp>