issue2538 gives a case where a changeset is merged with its child (which is on
another branch), and to my surprise the result is a real merge with two
parents, not just a "fast forward" "merge" with only the child as parent.
That is essentially the same as issue619.
Is the existing behaviour as intended and correct?
Or is the following fix correct?
Some extra "created new head" pops up with this fix, but it seems to me like
they could be considered correct. The old branch head has been superseeded by
changes on the other branch, and when the changes on the other branch is merged
back to the branch it will introduce a new head not directly related to the
previous branch head.
(I guess the intention with existing behaviour could be to ensure that the
changesets on the branch are directly connected and that no new heads pops up
on merges.)
See the Hg Book on why we actually want to detect this case:
http://hgbook.red-bean.com/read/mercurial-in-daily-use.html#id364290
Before:
$ hg up deadbeef
warning: detected divergent renames of X to:
...
After:
$ hg up deadbeef
note: possible conflict - X was renamed multiple times to:
...
No functionality change.
When using "hg update" to update to a revision on another branch, if
the user has uncommitted changes in the working directory, hg aborts
with the following message:
abort: crosses branches (use 'hg merge' to merge or use 'hg update
-C' to discard changes)
If the user isn't trying to update to tip and they follow the command
examples verbatim, they would end up updating to the wrong revision.
This patch removes the command examples in favor of just telling the
user to either merge or use --clean:
abort: crosses branches (merge branches or use --clean to discard
changes)
hg also aborts if the user tries to use "hg update" to get to tip
(without specifying a revision) and tip is on another branch:
abort: crosses branches (use 'hg merge' or use 'hg update -c')
This message is changed in the same fashion:
abort: crosses branches (merge branches or use --check to force
update)
I managed to get an empty .hg/merge/state file by interrupting a merge
by pressing Control-C. This lead to this error:
TypeError: a2b_hex() argument 1 must be string or read-only buffer,
not None
since localnode is assigned None before the iteration over lines in
the mergestate begins.
In the case a file is locally tracked as copied in dirstate, and that a merge
affects this file, this file should not be marked as modified in dirstate, as
this will break the current copy state.
Note: only affect working directory merge, not branch merge.
Update will now allow crossing branches within the same named branch,
when given a specific revision, if the working dir is clean, without
requiring the -c or -C option. Abort if no revision is given and
this would cross branches. Minor change to abort message if
uncommitted changes are found.
Modify test-update-branches and output to reflect the altered case. Modify
test-merge5.out to reflect the altered case. Modify
test-up-local-change.out with new message.
Add comment to merge.py:update() showing various cases of 'hg update': to a
descendant, crossing named branches, and crossing branches within a named
branch; with no option, -c or -C; with or without uncommitted changes; and
with or without a specific revision. Add tests for all of these cases.
