[PATCH RFC] update: add an option to allow to merge local changes when crossing branches
martin at geisler.net
Fri Feb 22 14:35:02 CST 2013
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: not available
More information about the Mercurial-devel