[PATCH RFC] update: add an option to allow to merge local changes when crossing branches
kbullock+mercurial at ringworld.org
Fri Feb 22 14:54:37 CST 2013
On 22 Feb 2013, at 2:35 PM, Martin Geisler wrote:
> 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.
Huh, how long have we been doing that? And more importantly, if we allowed a cross-branch update, how would you get them back _after updating back to your original place_?
> I don't know why you say the risk of conflicts is greater here than with
> any other update/merge?
Simply because you're merging a larger set of changes, as you get to below.
>> 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.
That's what I was describing, yes: base is the working copy parent, and the two merge 'heads' are the target rev and the uncommitted working copy changes.
>> 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.
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).
pacem in terris / мир / शान्ति / سَلاَم / 平和
Kevin R. Bullock
More information about the Mercurial-devel