Makes the 'nothing to merge' abort messages in commands.py consistent with
those in merge.py. Also makes commands.merge() and merge.update() use hints.
The tests show the changes.
Some character sets, cp932 (known as Shift-JIS for Japanese) for
example, use 0x41('A') - 0x5A('Z') and 0x61('a') - 0x7A('z') as second
or later character.
In such character set, case collision checking recognizes different
files as CASEFOLDED same file, if filenames are treated as byte
sequence.
win32mbcs extension is not appropriate to handle this problem, because
this problem can occur on other than Windows platform only if
problematic character set is used.
Callers of util.checkcase() use known ASCII filenames as last
component of path, and string.lower() is not applied to directory part
of path. So, util.checkcase() is kept intact, even though it applies
string.lower() to filenames.
merge.update() was missing a few dirtiness checks from workingcontext,
including subrepo cleanliness checks. Using wc.dirty() instead of
one-off checks for various forms of dirtiness will be significantly
safer.
Previously, pull would not update if new branch heads were received,
whereas pull && update would move to the tipmost branch head.
Also change the "crosses branches" abort in merge.update from
"crosses branches (merge branches or use --check to force update)"
to
"crosses branches (merge branches or update --check to force update)"
since it can no longer assume the user is running hg update.
It has substantially different semantics from forget at the command
layer, so change it to avoid confusion.
We can't simply combine it with remove because we need to explicitly
drop non-added files in some cases like commit.
The Mercurial 1.9 release is moving a lot of stuff around anyway and we are
already moving path_auditor from util.py to scmutil.py for that release.
So this seems like a good opportunity to do such a rename. It also strengthens
the current project policy to avoid underbars in names.
These leaks may occur in environments that don't employ a reference
counting GC, i.e. PyPy.
This implies:
- changing opener(...).read() calls to opener.read(...)
- changing opener(...).write() calls to opener.write(...)
- changing open(...).read(...) to util.readfile(...)
- changing open(...).write(...) to util.writefile(...)
This backs out
changeset: 13158:17d1b96c0f12
user: Mads Kiilerich <mads@kiilerich.com>
date: Tue Dec 07 03:29:21 2010 +0100
summary: merge: fast-forward merge with descendant
Before named branches, the invariants were:
a) "merges" always have two parents
b) p1 is not linearly related to p2
Adding named branches made (b) problematic, so the above patch was
introduced, which fixed (b) but broke (a).
After discussion, we decided that the invariants should be:
a) "merges" always have two parents
b) p1 is not linearly related to p2 OR p1 and p2 are on different branches
Add missing calls to close() to many places where files are
opened. Relying on reference counting to catch them soon-ish is not
portable and fails in environments with a proper GC, such as PyPy.
This makes 'hg update --clean' behave the same way for both kinds of
subrepositories. Before Subversion subrepos did not take the clean
parameter into account, but just updated to the given revision and
merged uncommitted changes into that.
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.
bed0e312bdf5 introduced fast-forward branch merging.
e2079edce509 partly removed it again.
The fastforward variable would always be false if branchmerge was false, so the
fastforward variable makes no difference and we can remove it completely.
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.
New behavior is generally superior and more correct, except possibly
with regards to missing files. hg up . is now effectively a no-op,
which is probably the desired behavior for people expecting to move to
tip, but may surprise people who were expecting deleted files to
reappear.
case 1: update to .
a-w -> a-w
classic: ancestor a
missing recreated right?
rmed recreated WRONG
added forgotten WRONG
changed preserved RIGHT
conflicted can't happen
backward merge: ancestor a (NO EFFECT)
missing missing wrong?
rm'ed rm'ed RIGHT
added preserved RIGHT
changed preserved RIGHT
conflicted can't happen
case 2: update to ancestor of .
a-b-w -> b-w
\
a
classic: ancestor a
missing recreated right?
rmed recreated wrong?
added forgotten wrong?
changed preserved RIGHT
conflicted preserved wrong?
backwards merge: ancestor b
missing missing or conflict right?
rm'ed missing or conflict right?
changed preserved RIGHT
conflicted merge RIGHT
added preserved right?
Use ampersands (&) to delineate the response char in each choice.
ui.prompt() responses are now explicitly case insensitive. GUIs
that subclass ui can generate dialogs from the full choice names.
This should be faster and more future-proof. Calls where the result is to be
sorted using util.sort() have been left unchanged. Calls to .items() on
configparser objects have been left as-is, too.
This change ensures that removes happen first in applyupdates(). This avoids
issues where we try to make a case-only rename of a file on a case insensitive
system. Without this patch, the add of the new name happens before the remove
of the old one - which results in the file not existing, as the two names are
effectively the same.
With the patch, the old name gets removed then the new one gets added, which
is always safe.
- complain about attempts to merge with ancestor
- when updating, differentiate between
- crossing named branches with no local changes (jump)
- crossing named branches with local changes (complain)
- nonlinear update on the same named branch, no changes (complain some more)
- nonlinear update on the same named branch, changes (different complaining)
As mentioned in msg5349 in issue988, "hg update" doesn't take into account
uncommitted copies. To reproduce:
----------------
hg init repo
cd repo
touch foo
hg ci -Am 'add foo'
echo >> foo
hg ci -m 'change foo'
hg up -C 0
hg mv foo bar
HGMERGE=false thg --debug -y update
--------------------------
A similar problem happens with hg merge --force.
I'm attaching a possible patch.
Sets HG_MY_ISLINK, HG_OTHER_ISLINK, HG_BASE_ISLINK in environment. Without these variables, it's impossible for the merge application to know whether the 'other' and 'base' files were symlinks in their original contexts. For the purposes of the merge they are always emitted as small text files.
After a hg merge, we want to include in the commit all the files that we
got from the second parent, so that we have the correct file-level
history. To make them visible to hg commit, we try to mark them as dirty.
Unfortunately, right now we can't really mark them as dirty[1] - the
best we can do is to mark them as needing a full comparison of their
contents, but they will still be considered clean if they happen to be
identical to the version in the first parent.
This changeset extends the dirstate format in a compatible way, so that
we can mark a file as dirty:
Right now we use a negative file size to indicate we don't have valid
stat data for this entry. In practice, this size is always -1.
This patch uses -2 to indicate that the entry is dirty. Older versions
of hg won't choke on this dirstate, but they may happily mark the file
as clean after a full comparison, destroying all of our hard work.
The patch adds a dirstate.normallookup method with the semantics of the
current normaldirty, and changes normaldirty to forcefully mark the
entry as dirty.
This should fix issue522.
[1] - well, we could put them in state 'm', but that state has a
different meaning.
When merging rev1 and rev2, we want to search for copies that happened
in rev1 but not in rev2 and vice-versa. We were starting the search at
rev1/rev2 and then going back, stopping as soon as we reached the revno
of the ancestor, but that can miss some cases (see the new
test-issue672).
Now we calculate the revisions that are ancestors of rev1 or rev2 (but
not both) and make sure the search doesn't stop too early.
Simplified test provided by mpm, based on a test case provided by
Edward Lee.
The following properties of a path are now checked for:
- under top-level .hg
- starts at the root of a windows drive
- contains ".."
- traverses a symlink (e.g. a/symlink_here/b)
- inside a nested repository
If any of these is true, the path is rejected.
The check for traversing a symlink is arguably stricter than necessary;
perhaps we should be checking for symlinks that point outside the
repository.
Without copies/renames, merges source names are 1:1 with their
targets. Copies and renames introduce the possibility that there will
be two merges with the same input but different output. By doing the
copy to the destination name before the merge, the actual merge
becomes 1:1 again, and no source is the input to two different merges.
- add a preliminary scan to applyupdates to do copies
- for the merge action, pass the old name (for finding ancestors) and
the new name (for input to the merge) to filemerge
- eliminate the old post-merge copy
- lookup file contents from new name in filemerge
- pass new name to external merge helper
- report merge failure at new name
- add a test
commit: handle new copy dirstate case correctly
findcopies:
keep a map of all copies found for directory logic
add dirs filter
check for merge:followdirs config option
generate a directory move map
find files that match directory move map
manifestmerge:
add directory rename cases
applyupdates:
skip actions with None file
add "d" action
recordupdates:
add "d" action
add simple directory rename test
- we don't actually need the context in recordupdates
- use -1 for filesize to force check on normal update
- only record copy for branchmerges
- forget moved files on update
- eliminate my and other from merge and copy
- eliminate node from get
- use mctx for get
- fix bug flag = a[2:]
- pass mctx to recordupdates
- use new filectx.size in recordupdates
record copies in dirstate even if rename was remote
this lets us record it properly at commit
teach checkfilemerge about copies, including merge cases
pull old copy code out of commit
extend rename-merge1 test to show file index
findcopies: ignore files renamed on both branches
applyupdates: change remove flag to move
recordupdates: record copy actions, including local moves and deletions
This adds findcopies, which detects merge-relevant copies between
files in a pair of manifests back to the merge ancestor.
While the merge code invokes the copy detection routine, it does not
yet use the result.