updating across branches with local modifications (WAS: Why I Switched to Git from Mercurial)
Chad Dombrova
chadrik at gmail.com
Mon May 24 02:34:46 UTC 2010
>>> You're right - that does the right thing (i.e. - not what you
>>> want). Apparently, hg only copies uncommitted changes if the place you
>>> are updating to is an ancestor or descendant of the working copies
>>> parent. Personally, I think it should always prompt you to merge
>>> (maybe it ought to mention the -f flag), because you *are* doing a
>>> merge, but an alias can arrange that for me. git, on the other hand,
>>> does the merge, doing Linus-knows-what (hopefully) with the conflict
>>> in the merge.
>>
>> that's not quite right. git only does the update if the edited files have not changed between branches. this ensures that there won't be conflicts. if they are different it won't let you change branches. so where hg says "no way, not under any circumstances" git says "let me check if this is safe. ok, let's do it".
>
> The problem is, git only checks the files that have uncommitted
> changes. If you actually do the merge, you may well discover that
> there are conflicts in files that don't have any uncommitted
> changes. In fact, the example that's been used here does exactly
> that. So you copy your change over, only to discover that feature X
> from file bar (that had no uncommitted changes) that your changes use
> only exists in the branch you started on, not the branch you are now
> working on. You'd have to be a real git to commit that.
when you say "conflict" you don't mean in the resolve-merge-conflict sense (kdiff, meld, etc), do you? because the unmodified file bar is just going to be replaced wholesale, there's no chance of a merge conflict because it's not merging with anything. but, yes, there could be a conflict in the sense that edits to file foo use a feature from file bar that does not exist on the destination branch. i wouldn't use the word conflict to describe this. maybe just "mistake".
>> technically speaking, would it be that difficult for hg to check if all modified files in the update rev are the same as those at the parent of the working state?
>
> How about adding a "-f/--force" option to update, which does it even
> with outstanding changes? This is designed for the case of "Oh shit,
> I forgot to change branches before starting editing". So it wouldn't
> even have the limits git has; it would update all files that didn't
> have uncommitted changes, and merge the files that did, and if there
> were conflicts, it'd leave it up to you to resolve. That's actually
> what you want in this case, isn't it?
yes, i was independently coming to the same conclusion. it also has the advantage of maintaining the current behavior by default. do you think there is a chance of getting this kind of change implemented?
one thing i'm a little bit confused about: what does `hg update --check` do? the docs say:
"The following rules apply when the working directory contains uncommitted changes:
...
With the -c/--check option, the update is aborted and the uncommitted changes are preserved. "
isn't that the default behavior? is this there for historic reasons? was there a time when what i'm asking for was actually the default?
-chad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20100523/850901ef/attachment.html>
More information about the Mercurial
mailing list