We allow rebase plus collapse, but not collapse only? I imagine people would
rebase first then collapse once they are sure the rebase is correct and it is
the right time to finish it.
I was reluctant to submit this patch for reasons detailed below, but it
improves rebase --collapse usefulness so much it is worth the ugliness.
The fix is ugly because we should be fixing the collapse code path rather than
the merge. Collapsing by merging changesets repeatedly is inefficient compared
to what commit --amend does: commitctx(), update, strip. The problem with the
latter is, to generate the synthetic changeset, copy records are gathered with
copies.pathcopies(). copies.pathcopies() is still implemented with merging in
mind and discards information like file replaced by the copy of another,
criss-cross copies and so forth. I believe this information should not be lost,
even if we decide not to interpret it fully later, at merge time.
The second issue with improving rebase --collapse is the option should not be
there to begin with. Rebasing and collapsing are orthogonal and a dedicated
command would probably enable a better, simpler ui. We should avoid advertizing
rebase --collapse, but with this fix it becomes the best shipped solution to
collapse changesets.
And for the record, available techniques are:
- revert + commit + strip: lose copies
- mq/qfold: repeated patching() (mostly correct, fragile)
- rebase: repeated merges (mostly correct, fragile)
- collapse: revert + tag rewriting wizardry, lose copies
- histedit: repeated patching() (mostly correct, fragile)
- amend: copies.pathcopies() + commitctx() + update + strip
The fix introduced in 3509b9cf8f86 was only partially successful. It is correct
to turn dirstate 'm' merge records into normal/dirty ones but copy records are
lost in the process. To adjust them as well, we need to look in the first
parent manifest to know which files were added and preserve only related
records. But the dirstate does not have access to changesets, the logic has to
moved at another level, in localrepo.
a317664437ee introduced some logic to avoid case-collision detection between
source and destination revisions when it does not make sense: clean or to be
cleaned working directories. Unfortunately, part of it was flawed and the
related test was broken by another bug.
This patch disables cross revision case collision detection for updates without
option or with --check, if the working directory is clean.
if the file in target context causes case-folding collision against
one in working context, current implementation aborts merging with it,
even thouhg collding one (in target) is the file renamed from collided
one (in working).
this patch uses file copy information to know whether colliding file
is renamed from collided one or not: if so, collision between them is
ignored.
this patch also avoids collision detection between current context and
target context, if working context is clean (with --check/-c) or will
be clean (with --clean/-C).
This fixes a regression introduced by df049e784ab6. If no file-level
merge is needed, we can update flags directly, otherwise we have a
conflict to resolve in filemerge.
Previously, we could change a normal file into a corrupt symlink when
trying to merge a symlink flag. Now, we leave the flag alone and let
filemerge deal with it (usually by a prompt).
We also drop a redundant flag setting after filemerge (now dealt with
by ms.resolve) that would cause similar corruption.
The unknown file collision rule was introduced as an extension of the
"should be clean when merging" rule. Unfortunately, it got applied to
the normal update path, which should be happy to merge local changes.
This patch gives us merges for unknown file collisions on update,
while preserving abort for merge and update -c.
This removes use of unknown files for building the synthetic working
directory manifest used by manifestmerge. Instead, we adopt the
strategy used by _checkunknown.
Side-effect: unknown files are no longer moved by remote directory
renames, and now are left alone like ignored files.
Previously, we would do a full working directory walk including
unknown files to perform a merge. In many cases, this was painful
because unknown files greatly outnumbered tracked files and generally
had no useful effect on the merge.
Here we instead wait until we find a file in the destination that's
not tracked locally and detect if it exists and is not ignored. This
is usually cheaper but can be -more- expensive in the case where we're
adding a huge number of files. On the other hand, the cost of statting
the new files should be dwarfed by the cost of eventually writing
them.
In this version, case collisions are detected implicitly by
os.path.exists and wctx[f] lookup.
When doing hg up, if there is a file conflict with untracked files,
currently only the first such conflict is reported. With this patch,
all of them are listed.
With this patch error message is now reported as
a: untracked file differs
b: untracked file differs
abort: untracked files in working directory conflict with files in
requested revision
instead of
abort: untracked file in working directory differs from file in
requested revision: 'a'
This is a follow up to an old attempt to do this here:
http://selenic.com/pipermail/mercurial-devel/2011-August/033625.html
this patch makes branch merging abort when merged changesets have same
file in different case on case insensitive filesystem.
this patch does not prevent linear update which merges between target
and working contexts, because 'branchmerge' is False in such case.
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