Mercurial > hg
view tests/test-patch.t @ 42595:819712deac69
copies: follow copies across merge base without source file (issue6163)
As in the previous patch, consider these two histories:
@ 4 'rename x to y'
|
o 3 'add x again'
|
o 2 'remove x'
|
| o 1 'modify x'
|/
o 0 'add x'
@ 4 'rename x to y'
|
o 3 'add x again'
|
| o 2 'modify x'
| |
| o 1 'add x'
|/
o 0 'base'
We trace copies from the 'modify x' commit to commit 4 by going via
the merge base (commit 0). When tracing file 'y' (_tracefile()) in the
first case, we immediately find the rename from 'x'. We check to see
if 'x' exists in the merge base, which it does, so we consider it a
valid copy. In the second case, 'x' does not exist in the merge base,
so it's not considered a valid copy. As a workaround, this patch makes
it so we also attempt the check in mergecopies's base commit (commit 1
in the second case). That feels pretty ugly to me, but I don't have
any better ideas.
Note that we actually also check not only that the filename matches,
but also that the file's nodeid matches. I don't know why we do that,
but it was like that already before I rewrote mergecopies(). That
means that the rebase will still fail in cases like this (again, it
already failed before my rewrite):
@ 4 'rename x to y'
|
o 3 'add x again with content X2'
|
o 2 'remove x'
|
| o 1 'modify x to content X2'
|/
o 1 'modify x to content X1'
|
o 0 'add x with content X0'
Differential Revision: https://phab.mercurial-scm.org/D6604
author | Martin von Zweigbergk <martinvonz@google.com> |
---|---|
date | Fri, 28 Jun 2019 12:59:21 -0700 |
parents | 5abc47d4ca6b |
children | 42d2b31cee0b |
line wrap: on
line source
$ cat > patchtool.py <<EOF > from __future__ import absolute_import, print_function > import sys > print('Using custom patch') > if '--binary' in sys.argv: > print('--binary found !') > EOF $ echo "[ui]" >> $HGRCPATH $ echo "patch=\"$PYTHON\" ../patchtool.py" >> $HGRCPATH $ hg init a $ cd a $ echo a > a $ hg commit -Ama -d '1 0' adding a $ echo b >> a $ hg commit -Amb -d '2 0' $ cd .. This test checks that: - custom patch commands with arguments actually work - patch code does not try to add weird arguments like --binary when custom patch commands are used. For instance --binary is added by default under win32. check custom patch options are honored $ hg --cwd a export -o ../a.diff tip $ hg clone -r 0 a b adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files new changesets 8580ff50825a updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg --cwd b import -v ../a.diff applying ../a.diff Using custom patch applied to working directory Issue2417: hg import with # comments in description Prepare source repo and patch: $ rm $HGRCPATH $ hg init c $ cd c $ printf "a\rc" > a $ hg ci -A -m 0 a -d '0 0' $ printf "a\rb\rc" > a $ cat << eof > log > first line which can't start with '# ' > # second line is a comment but that shouldn't be a problem. > A patch marker like this was more problematic even after d7452292f9d3: > # HG changeset patch > # User lines looks like this - but it _is_ just a comment > eof $ hg ci -l log -d '0 0' $ hg export -o p 1 $ cd .. Clone and apply patch: $ hg clone -r 0 c d adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files new changesets 7fadb901d403 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd d $ hg import ../c/p applying ../c/p $ hg log -v -r 1 changeset: 1:cd0bde79c428 tag: tip user: test date: Thu Jan 01 00:00:00 1970 +0000 files: a description: first line which can't start with '# ' # second line is a comment but that shouldn't be a problem. A patch marker like this was more problematic even after d7452292f9d3: # HG changeset patch # User lines looks like this - but it _is_ just a comment Error exit (issue4746) $ cat >> exit1.py <<EOF > import sys > sys.exit(1) > EOF $ hg import ../c/p --config ui.patch="\"$PYTHON\" \"`pwd`/exit1.py\"" applying ../c/p abort: patch command failed: exited with status 1 [255] $ cd ..