[Bug 5125] New: Allow cross-branch updates with uncommitted changes in the working copy

Brandon McCaig bamccaig at gmail.com
Fri Mar 4 12:23:42 EST 2016


(snipped quote for compactness and relevance)

> ...a 3-way merge...does the right thing for cross-branch
> updates also.
> 
> I suggest adding a "-f", "--force" option to just override the
> ancestor/descendant check, but still use the merge mechanism
> normally used for updating.
> 
> This is an svn-parity issue, as Subversion is able to perform a
> "switch" operation (equivalent to cross-branch update in Hg)
> with working copy changes in the way. I believe it's also
> git-parity.

I believe that Git is actually a little bit smarter about this,
and that's the direction I'd prefer Mercurial to move in too. My
understanding is that Git essentially tries the merge (whether in
memory or where, I'm not sure, but without touching the working
tree), and if successful it follows through. If there are
conflicts then I think Git refuses to checkout (i.e., "update")
the other branch.

This is very useful because it saves the user undesired work in
all cases: if it works it works, and if it doesn't work Git
doesn't force you into conflict resolution. If you really want
the conflict resolution then you can stash (i.e., shelve), or
commit and rebase. By using those mechanisms there is a safety
net to change your mind. If you just move forward with the merge
and the conflicts become unbearable the user has to do ugly,
error-prone work to get back to coding.

What we want is an "easy button". Do the "best" thing in all
cases. This should also apply to same-branch updates... If it's
going to conflict then I'd prefer it to abort and let me get
there through more reliable channels.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160304/64d85cc4/attachment.sig>


More information about the Mercurial-devel mailing list