facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 15:27:13 +03:00
Code Issues Projects Releases Wiki Activity
917604f2f5
sapling/tests/test-rebase-conflicts.t

429 lines
11 KiB
Perl
Raw Normal View History

tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
$ cat >> $HGRCPATH <<EOF
test: use generaldelta in 'test-rebase-conflict.t' Doing this has some minor impacts on test output since the rebase backup bundle moves to bundle2.
2015-10-20 04:14:36 +03:00
> [format]
> usegeneraldelta=yes
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
> [extensions]
> rebase=
>
phases: prevent rebase to rebase immutable changeset.
2011-12-27 03:11:22 +04:00
> [phases]
> publish=False
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
> EOF
$ hg init a
$ cd a
$ echo c1 >common
$ hg add common
$ hg ci -m C1
$ echo c2 >>common
$ hg ci -m C2
$ echo c3 >>common
$ hg ci -m C3
$ hg up -q -C 1
$ echo l1 >>extra
$ hg add extra
$ hg ci -m L1
$ sed -e 's/c2/l2/' common > common.new
$ mv common.new common
$ hg ci -m L2
$ echo l3 >> extra2
$ hg add extra2
$ hg ci -m L3
rebase: restore active bookmark after rebase --continue When a rebase has conflicts and the user uses rebase --continue, the previously active bookmark was not being made active once again. With this change that bookmark is made active again, just as if the rebase had never been interrupted. This changes the rebasestate file format, but should handle old formats correctly. Since the file is transient, this is even less of a problem. Adds a test to verify the new behavior. I manually tested continuing rebases with and without an active bookmark, and with and without being on the bookmark being rebased.
2013-03-12 02:37:28 +04:00
$ hg bookmark mybook
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
rebase: fix phases movement Rebase now try to keep the phases of source changesets.
2012-01-17 12:12:14 +04:00
$ hg phase --force --secret 4
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
$ tglogp
@ 5: 8029388f38dc secret 'L3' mybook
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 4: 46f0b057b5c0 secret 'L2'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 3: 3163e20567cc draft 'L1'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
| o 2: a9ce13b75fb5 draft 'C3'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|/
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 1: 11eb9c356adf draft 'C2'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 0: 178f1774564f draft 'C1'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
Try to call --continue:
$ hg rebase --continue
abort: no rebase in progress
[255]
Conflicting rebase:
$ hg rebase -s 3 -d 2
rebase: show more useful status information while rebasing Show status messages while rebasing, similar to what graft do: rebasing 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.
2014-12-09 05:45:26 +03:00
rebasing 3:3163e20567cc "L1"
rebasing 4:46f0b057b5c0 "L2"
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
merging common
simplemerge: move conflict warning message to filemerge The current output for a failed merge with conflict markers looks something like: merging foo warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') merging bar warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') We're going to change the way merges are done to perform all premerges before all merges, so that the output above would look like: merging foo merging bar warning: conflicts during merge. merging foo incomplete! (edit conflicts, then use 'hg resolve --mark') warning: conflicts during merge. merging bar incomplete! (edit conflicts, then use 'hg resolve --mark') The 'warning: conflicts during merge' line has no context, so is pretty confusing. This patch will change the future output to: merging foo merging bar warning: conflicts while merging foo! (edit, then use 'hg resolve --mark') warning: conflicts while merging bar! (edit, then use 'hg resolve --mark') The hint on how to resolve the conflicts makes this a bit unwieldy, but solving that is tricky because we already hint that people run 'hg resolve' to retry unresolved merges. The 'hg resolve --mark' mostly applies to conflict marker based resolution.
2015-10-09 23:54:52 +03:00
warning: conflicts while merging common! (edit, then use 'hg resolve --mark')
rebase: switch from util.Abort to util.InterventionRequired where appropriate (bc)
2013-02-09 02:27:59 +04:00
unresolved conflicts (see hg resolve, then hg rebase --continue)
dispatch: exit with status 1 for an InterventionRequired exception (bc)
2013-02-09 02:17:46 +04:00
[1]
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
morestatus: move fb extension to core by plugging to `hg status --verbose` morestatus extension in fbext use to show more context about the state of the repo like the repository is in a unfinished merge state, or a rebase is going on, or histedit is going on, listing the files which need to be resolved and also suggesting ways to handle the situation. This patch moves the extension directly to core by plugging it into the --verbose flag of the status command. So now if you are in any unfinished state and you do hg status -v, it will show you details and help related to the state. The extension in fbext also shows context about unfinished update state which is not ported to core as that plug in hooks to update command which need to be tackled somewhat differently. The following configuration will turn the behaviour on by default [commands] status.verbose = 1 You can also skip considering some states like bisect as follows: [commands] status.skipstates=bisect This patch also adds test for the feature. .. feature:: ``hg status -v`` can now show unfinished state. For example, when in an unfinished rebase state, ``hg status -v`` might show:: # The repository is in an unfinished *rebase* state. # No unresolved merge conflicts. # To continue: hg rebase --continue # To abort: hg rebase --abort Differential Revision: https://phab.mercurial-scm.org/D219
2017-08-03 02:42:35 +03:00
$ hg status --config commands.status.verbose=1
M common
? common.orig
# The repository is in an unfinished *rebase* state.
# Unresolved merge conflicts:
#
# common
#
# To mark files as resolved: hg resolve --mark FILE
# To continue: hg rebase --continue
# To abort: hg rebase --abort
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
Try to continue without solving the conflict:
check-code: fix check for trailing whitespace on sh command lines The $ has been without necessary escaping since introduced in c4ecbbd282fe.
2012-08-08 20:10:16 +04:00
$ hg rebase --continue
localrepo: use single quotes in use warning
2016-09-21 02:48:08 +03:00
abort: unresolved merge conflicts (see 'hg help resolve')
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
[255]
Conclude rebase:
$ echo 'resolved merge' >common
$ hg resolve -m common
resolve: add parenthesis around "no more unresolved files" message This message may be confused with an error message. Adding parenthesis around it will make it more recognisable as an informative message.
2014-07-26 05:32:49 +04:00
(no more unresolved files)
rebase: hook afterresolvedstates
2015-12-24 23:41:40 +03:00
continue: hg rebase --continue
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
$ hg rebase --continue
rebase: show more useful status information while rebasing Show status messages while rebasing, similar to what graft do: rebasing 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.
2014-12-09 05:45:26 +03:00
already rebased 3:3163e20567cc "L1" as 3e046f2ecedb
rebasing 4:46f0b057b5c0 "L2"
rebasing 5:8029388f38dc "L3" (mybook)
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
saved backup bundle to $TESTTMP/a/.hg/strip-backup/3163e20567cc-5ca4656e-rebase.hg
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
$ tglogp
@ 5: d67b21408fc0 secret 'L3' mybook
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 4: 5e5bd08c7e60 secret 'L2'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 3: 3e046f2ecedb draft 'L1'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 2: a9ce13b75fb5 draft 'C3'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 1: 11eb9c356adf draft 'C2'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 0: 178f1774564f draft 'C1'
tests: unify test-rebase*
2010-10-01 18:10:06 +04:00
Check correctness:
$ hg cat -r 0 common
c1
$ hg cat -r 1 common
c1
c2
$ hg cat -r 2 common
c1
c2
c3
$ hg cat -r 3 common
c1
c2
c3
$ hg cat -r 4 common
resolved merge
$ hg cat -r 5 common
resolved merge
rebase: restore active bookmark after rebase --continue When a rebase has conflicts and the user uses rebase --continue, the previously active bookmark was not being made active once again. With this change that bookmark is made active again, just as if the rebase had never been interrupted. This changes the rebasestate file format, but should handle old formats correctly. Since the file is transient, this is even less of a problem. Adds a test to verify the new behavior. I manually tested continuing rebases with and without an active bookmark, and with and without being on the bookmark being rebased.
2013-03-12 02:37:28 +04:00
Bookmark stays active after --continue
$ hg bookmarks
* mybook 5:d67b21408fc0
tests: add missing trailing 'cd ..' Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
2012-06-11 03:40:51 +04:00
$ cd ..
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
Check that the right ancestors is used while rebasing a merge (issue4041)
$ hg clone "$TESTDIR/bundles/issue4041.hg" issue4041
requesting all changes
adding changesets
adding manifests
adding file changes
added 11 changesets with 8 changes to 3 files (+1 heads)
transaction-summary: show the range of new revisions upon pull/unbundle (BC) Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
2017-10-12 10:39:50 +03:00
new changesets 24797d4f68de:2f2496ddf49d
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd issue4041
$ hg log -G
o changeset: 10:2f2496ddf49d
|\ branch: f1
| | tag: tip
| | parent: 7:4c9fbe56a16f
| | parent: 9:e31216eec445
| | user: szhang
| | date: Thu Sep 05 12:59:39 2013 -0400
| | summary: merge
| |
| o changeset: 9:e31216eec445
| | branch: f1
| | user: szhang
| | date: Thu Sep 05 12:59:10 2013 -0400
| | summary: more changes to f1
| |
| o changeset: 8:8e4e2c1a07ae
| |\ branch: f1
| | | parent: 2:4bc80088dc6b
| | | parent: 6:400110238667
| | | user: szhang
| | | date: Thu Sep 05 12:57:59 2013 -0400
| | | summary: bad merge
| | |
o | | changeset: 7:4c9fbe56a16f
|/ / branch: f1
| | parent: 2:4bc80088dc6b
| | user: szhang
| | date: Thu Sep 05 12:54:00 2013 -0400
| | summary: changed f1
| |
| o changeset: 6:400110238667
| | branch: f2
| | parent: 4:12e8ec6bb010
| | user: szhang
| | date: Tue Sep 03 13:58:02 2013 -0400
| | summary: changed f2 on f2
| |
| | @ changeset: 5:d79e2059b5c0
| | | parent: 3:8a951942e016
| | | user: szhang
| | | date: Tue Sep 03 13:57:39 2013 -0400
| | | summary: changed f2 on default
| | |
| o | changeset: 4:12e8ec6bb010
| |/ branch: f2
| | user: szhang
| | date: Tue Sep 03 13:57:18 2013 -0400
| | summary: created f2 branch
| |
| o changeset: 3:8a951942e016
| | parent: 0:24797d4f68de
| | user: szhang
| | date: Tue Sep 03 13:57:11 2013 -0400
| | summary: added f2.txt
| |
o | changeset: 2:4bc80088dc6b
| | branch: f1
| | user: szhang
| | date: Tue Sep 03 13:56:20 2013 -0400
| | summary: added f1.txt
| |
o | changeset: 1:ef53c9e6b608
|/ branch: f1
| user: szhang
| date: Tue Sep 03 13:55:26 2013 -0400
| summary: created f1 branch
|
o changeset: 0:24797d4f68de
user: szhang
date: Tue Sep 03 13:55:08 2013 -0400
summary: added default.txt
$ hg rebase -s9 -d2 --debug # use debug to really check merge base used
rebase: make debug logging more consistent We emit some lines that mix revision numbers with nodeids, which makes little sense to me.
2016-09-13 23:49:42 +03:00
rebase onto 4bc80088dc6b starting from e31216eec445
tests: add a simple test for in-memory rebase This is just a very simple start, but verifies some of the basic cases of an in-memory rebase. Differential Revision: https://phab.mercurial-scm.org/D1652
2017-12-11 09:39:46 +03:00
rebasing on disk
rebase: allow aborting if last-message.txt is missing Previously, if .hg/rebasestate existed but .hg/last-message.txt was missing, 'hg rebase --abort' would say there's no rebase in progress but 'hg checkout foo' would say 'abort: rebase in progress'. It turns out loading the collapse message will throw a "no rebase in progress" error if the file doesn't exist, even though .hg/rebasestate obviously indicates a rebase is in progress. The fix is to only throw an exception if we're trying to --continue, and to just eat the issues if we're doing --abort. This issue is exposed by us writing the rebase state earlier in the process. This will be used by later patches to ensure the user can appropriately 'hg rebase --abort' if there's a crash before the first the first commit has finished rebasing. Tests cover all of this. The only negative affect is we now require a hg rebase --abort in a very specific exception case, as shown in the test.
2017-03-08 03:30:31 +03:00
rebase status stored
rebase: show more useful status information while rebasing Show status messages while rebasing, similar to what graft do: rebasing 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.
2014-12-09 05:45:26 +03:00
rebasing 9:e31216eec445 "more changes to f1"
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
future parents are 2 and -1
rebase: backed out changeset 507f16f4aa51 (issue5610) Having a single transaction for rebase means the whole transaction gets rolled back on error. To work around this a small hack has been added to detect merge conflict and commit the work done so far before exiting. This hack works because there is nothing transaction related going on during the merge phase. However, if a hook blocks the rebase to create a changeset, it is too late to commit the work done in the transaction before the problematic changeset was created. This leads to the whole rebase so far being rolled back. Losing merge resolution and other work in the process. (note: rebase state will be fully lost too). Since issue5610 is a pretty serious regression and the next stable release is a couple day away, we are taking the backout route until we can figure out something better to do.
2017-06-27 18:40:24 +03:00
rebase status stored
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
update to 2:4bc80088dc6b
resolving manifests
branchmerge: False, force: True, partial: False
ancestor: d79e2059b5c0+, local: d79e2059b5c0+, remote: 4bc80088dc6b
f2.txt: other deleted -> r
removing f2.txt
merge: change debug logging - test output changes but no real changes Preparing for action list split-up, making sure the final change don't have any test changes. The patch moves debug statements around without really changing anything. Arguably, it temporarily makes the code worse. The only justification is that it makes it easier to review the test changes ... and in the end the big change will not change test output at all. The changes to test output are due to changes in the ordering of debug output. That is mainly because we now do the debug logging for files when we actually process them. Files are also processed in a slightly different but still correct order. It is now primarily ordered by action type, secondarily by filename. The patch introduces some redundancy. Some of it will be removed again, some of it will in the end help code readability and efficiency. It is possible that we later on could introduce a "process this action list and do some logging and progress reporting and apply this function". The "preserving X for resolve" debug statements will only have single space indentation. It will no longer have a leading single space indented "f: msg -> m" message. Having this message double indented would thus no longer make sense. The bid actions will temporarily be sorted using a custom sort key that happens to match the sort order the simplified code will have in the end.
2014-04-22 04:10:25 +04:00
f1.txt: remote created -> g
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
getting f1.txt
merge against 9:e31216eec445
detach base 8:8e4e2c1a07ae
searching for copies back to rev 3
mergecopies: invoke _computenonoverlap for both base and tca during merges The algorithm of _checkcopies can only walk backwards in the DAG, never forward. Because of this, the two _checkcopies patches need to run from their respective endpoints to the TCA to cover the entire subgraph where the merge is being performed. However, detection of files new in both endpoints, as well as directory rename detection, need to run with respect to the merge base, so we need lists of new files both from the TCA's and the merge base's viewpoint to correctly detect renames in a graft-like merge scenario. (Series reworked by Pierre-Yves David)
2016-10-13 03:19:43 +03:00
unmatched files in other (from topological common ancestor):
f2.txt
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
resolving manifests
branchmerge: True, force: True, partial: False
ancestor: 8e4e2c1a07ae, local: 4bc80088dc6b+, remote: e31216eec445
f1.txt: remote is newer -> g
getting f1.txt
localrepo: show headline notes in commitctx before showing filenames commitctx already showed notes with filenames but didn't provide any context. It is just as relevant to know when manifest or changelog is committed. So, in addition to filenames, also show headlines 'committing files:', 'committing manifest' and 'committing changelog'.
2014-04-18 15:33:20 +04:00
committing files:
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
f1.txt
localrepo: show headline notes in commitctx before showing filenames commitctx already showed notes with filenames but didn't provide any context. It is just as relevant to know when manifest or changelog is committed. So, in addition to filenames, also show headlines 'committing files:', 'committing manifest' and 'committing changelog'.
2014-04-18 15:33:20 +04:00
committing manifest
committing changelog
merge with stable
2017-06-30 01:21:52 +03:00
updating the branch cache
rebase: improve debug messages while processing the list of rebases
2014-12-10 08:20:35 +03:00
rebased as 19c888675e13
rebase: show more useful status information while rebasing Show status messages while rebasing, similar to what graft do: rebasing 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.
2014-12-09 05:45:26 +03:00
rebasing 10:2f2496ddf49d "merge" (tip)
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
future parents are 11 and 7
rebase: backed out changeset 507f16f4aa51 (issue5610) Having a single transaction for rebase means the whole transaction gets rolled back on error. To work around this a small hack has been added to detect merge conflict and commit the work done so far before exiting. This hack works because there is nothing transaction related going on during the merge phase. However, if a hook blocks the rebase to create a changeset, it is too late to commit the work done in the transaction before the problematic changeset was created. This leads to the whole rebase so far being rolled back. Losing merge resolution and other work in the process. (note: rebase state will be fully lost too). Since issue5610 is a pretty serious regression and the next stable release is a couple day away, we are taking the backout route until we can figure out something better to do.
2017-06-27 18:40:24 +03:00
rebase status stored
rebase: rename "target" to "destination" in messages The help text for rebase calls it "the destination" (never "target"), so let's use that in messages as well.
2017-05-12 08:38:15 +03:00
already in destination
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
merge against 10:2f2496ddf49d
detach base 9:e31216eec445
searching for copies back to rev 3
mergecopies: invoke _computenonoverlap for both base and tca during merges The algorithm of _checkcopies can only walk backwards in the DAG, never forward. Because of this, the two _checkcopies patches need to run from their respective endpoints to the TCA to cover the entire subgraph where the merge is being performed. However, detection of files new in both endpoints, as well as directory rename detection, need to run with respect to the merge base, so we need lists of new files both from the TCA's and the merge base's viewpoint to correctly detect renames in a graft-like merge scenario. (Series reworked by Pierre-Yves David)
2016-10-13 03:19:43 +03:00
unmatched files in other (from topological common ancestor):
f2.txt
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
resolving manifests
branchmerge: True, force: True, partial: False
ancestor: e31216eec445, local: 19c888675e13+, remote: 2f2496ddf49d
f1.txt: remote is newer -> g
getting f1.txt
localrepo: show headline notes in commitctx before showing filenames commitctx already showed notes with filenames but didn't provide any context. It is just as relevant to know when manifest or changelog is committed. So, in addition to filenames, also show headlines 'committing files:', 'committing manifest' and 'committing changelog'.
2014-04-18 15:33:20 +04:00
committing files:
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
f1.txt
localrepo: show headline notes in commitctx before showing filenames commitctx already showed notes with filenames but didn't provide any context. It is just as relevant to know when manifest or changelog is committed. So, in addition to filenames, also show headlines 'committing files:', 'committing manifest' and 'committing changelog'.
2014-04-18 15:33:20 +04:00
committing manifest
committing changelog
merge with stable
2017-06-30 01:21:52 +03:00
updating the branch cache
rebase: improve debug messages while processing the list of rebases
2014-12-10 08:20:35 +03:00
rebased as 2a7f09cac94c
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
rebase merging completed
update back to initial working directory parent
resolving manifests
branchmerge: False, force: False, partial: False
ancestor: 2a7f09cac94c, local: 2a7f09cac94c+, remote: d79e2059b5c0
f1.txt: other deleted -> r
removing f1.txt
merge: change debug logging - test output changes but no real changes Preparing for action list split-up, making sure the final change don't have any test changes. The patch moves debug statements around without really changing anything. Arguably, it temporarily makes the code worse. The only justification is that it makes it easier to review the test changes ... and in the end the big change will not change test output at all. The changes to test output are due to changes in the ordering of debug output. That is mainly because we now do the debug logging for files when we actually process them. Files are also processed in a slightly different but still correct order. It is now primarily ordered by action type, secondarily by filename. The patch introduces some redundancy. Some of it will be removed again, some of it will in the end help code readability and efficiency. It is possible that we later on could introduce a "process this action list and do some logging and progress reporting and apply this function". The "preserving X for resolve" debug statements will only have single space indentation. It will no longer have a leading single space indented "f: msg -> m" message. Having this message double indented would thus no longer make sense. The bid actions will temporarily be sorted using a custom sort key that happens to match the sort order the simplified code will have in the end.
2014-04-22 04:10:25 +04:00
f2.txt: remote created -> g
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
getting f2.txt
changegroup: properly compute common base in changeggroupsubset (issue4736) The computation of roots was buggy, any ancestor of a bundled merge which was also a descendant of the parents of a bundled revision were included as part of the bundle. We fix it and add a test for strip (which revealed the problem). Check the test for a practical usecase.
2015-06-29 21:20:09 +03:00
2 changesets found
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
list of changesets:
e31216eec445e44352c5f01588856059466a24c9
2f2496ddf49d69b5ef23ad8cf9fb2e0e4faf0ac2
strip: include phases in bundle (BC) Before this patch, unbundling a stripped changeset would make it a draft (unless the parent was secret). This meant that one would lose phase information when stripping and unbundling secret changesets. The same thing was true for public changesets. While stripping public changesets is generally rare, it's done frequently by e.g. the narrowhg extension. We also include the phases in the temporary bundle, just in case stripping were to fail after that point, so the user can still restore the repo including phase information. Before this patch, the phases were left untouched during the bundling and unbundling of the temporary bundle. Only at the end of the transaction would phasecache.filterunknown() be called to remove phase roots that were no longer valid. We now need to call that also after the first stripping, i.e. before applying the temporary bundle. Otherwise unbundling the temporary bundle will cause a read of the phase cache which has stripped changesets in the cache and that fails. Like with obsmarkers, we unconditionally include the phases in the bundle when stripping (when using bundle2, such as when generaldelta is enabled). The reason for doing that for strip but not for bundle is that strip bundles are not meant to be shared outside the repo, so we don't care as much about compatibility.
2017-06-15 10:15:52 +03:00
bundle2-output-bundle: "HG20", (1 params) 2 parts total
bundle2: store changeset count when creating file bundles The bundle2 changegroup part has an advisory param saying how many changesets are in the part. Before this patch, we were setting this part when generating bundle2 parts via the wire protocol but not when generating local bundle2 files. A side effect of not setting the changeset count part is that progress bars don't work when applying changesets. As the tests show, this impacted clone bundles, shelve, backup bundles, `hg unbundle`, and anything touching bundle2 files. This patch adds a backdoor to allow us to pass state from changegroup generation into the unbundler. We store the number of changesets in the changegroup in this state and use it to populate the aforementioned advisory part parameter when generating the bundle2 bundle. I concede that I'm not thrilled by how state is being passed in changegroup.py (it feels a bit hacky). I would love to overhaul the rather confusing set of functions in changegroup.py with something that passes rich objects around instead of e.g. low-level generators. However, given the code freeze for 3.9 is imminent, I'd rather not undertake this endeavor right now. This feels like the easiest way to get the parameter added to the changegroup part.
2016-07-18 01:13:51 +03:00
bundle2-output-part: "changegroup" (params: 1 mandatory 1 advisory) streamed payload
strip: include phases in bundle (BC) Before this patch, unbundling a stripped changeset would make it a draft (unless the parent was secret). This meant that one would lose phase information when stripping and unbundling secret changesets. The same thing was true for public changesets. While stripping public changesets is generally rare, it's done frequently by e.g. the narrowhg extension. We also include the phases in the temporary bundle, just in case stripping were to fail after that point, so the user can still restore the repo including phase information. Before this patch, the phases were left untouched during the bundling and unbundling of the temporary bundle. Only at the end of the transaction would phasecache.filterunknown() be called to remove phase roots that were no longer valid. We now need to call that also after the first stripping, i.e. before applying the temporary bundle. Otherwise unbundling the temporary bundle will cause a read of the phase cache which has stripped changesets in the cache and that fails. Like with obsmarkers, we unconditionally include the phases in the bundle when stripping (when using bundle2, such as when generaldelta is enabled). The reason for doing that for strip but not for bundle is that strip bundles are not meant to be shared outside the repo, so we don't care as much about compatibility.
2017-06-15 10:15:52 +03:00
bundle2-output-part: "phase-heads" 24 bytes payload
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
saved backup bundle to $TESTTMP/issue4041/.hg/strip-backup/e31216eec445-15f7a814-rebase.hg
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
3 changesets found
list of changesets:
4c9fbe56a16f30c0d5dcc40ec1a97bbe3325209c
19c888675e133ab5dff84516926a65672eaf04d9
2a7f09cac94c7f4b73ebd5cd1a62d3b2e8e336bf
strip: include phases in bundle (BC) Before this patch, unbundling a stripped changeset would make it a draft (unless the parent was secret). This meant that one would lose phase information when stripping and unbundling secret changesets. The same thing was true for public changesets. While stripping public changesets is generally rare, it's done frequently by e.g. the narrowhg extension. We also include the phases in the temporary bundle, just in case stripping were to fail after that point, so the user can still restore the repo including phase information. Before this patch, the phases were left untouched during the bundling and unbundling of the temporary bundle. Only at the end of the transaction would phasecache.filterunknown() be called to remove phase roots that were no longer valid. We now need to call that also after the first stripping, i.e. before applying the temporary bundle. Otherwise unbundling the temporary bundle will cause a read of the phase cache which has stripped changesets in the cache and that fails. Like with obsmarkers, we unconditionally include the phases in the bundle when stripping (when using bundle2, such as when generaldelta is enabled). The reason for doing that for strip but not for bundle is that strip bundles are not meant to be shared outside the repo, so we don't care as much about compatibility.
2017-06-15 10:15:52 +03:00
bundle2-output-bundle: "HG20", 2 parts total
bundle2: store changeset count when creating file bundles The bundle2 changegroup part has an advisory param saying how many changesets are in the part. Before this patch, we were setting this part when generating bundle2 parts via the wire protocol but not when generating local bundle2 files. A side effect of not setting the changeset count part is that progress bars don't work when applying changesets. As the tests show, this impacted clone bundles, shelve, backup bundles, `hg unbundle`, and anything touching bundle2 files. This patch adds a backdoor to allow us to pass state from changegroup generation into the unbundler. We store the number of changesets in the changegroup in this state and use it to populate the aforementioned advisory part parameter when generating the bundle2 bundle. I concede that I'm not thrilled by how state is being passed in changegroup.py (it feels a bit hacky). I would love to overhaul the rather confusing set of functions in changegroup.py with something that passes rich objects around instead of e.g. low-level generators. However, given the code freeze for 3.9 is imminent, I'd rather not undertake this endeavor right now. This feels like the easiest way to get the parameter added to the changegroup part.
2016-07-18 01:13:51 +03:00
bundle2-output-part: "changegroup" (params: 1 mandatory 1 advisory) streamed payload
strip: include phases in bundle (BC) Before this patch, unbundling a stripped changeset would make it a draft (unless the parent was secret). This meant that one would lose phase information when stripping and unbundling secret changesets. The same thing was true for public changesets. While stripping public changesets is generally rare, it's done frequently by e.g. the narrowhg extension. We also include the phases in the temporary bundle, just in case stripping were to fail after that point, so the user can still restore the repo including phase information. Before this patch, the phases were left untouched during the bundling and unbundling of the temporary bundle. Only at the end of the transaction would phasecache.filterunknown() be called to remove phase roots that were no longer valid. We now need to call that also after the first stripping, i.e. before applying the temporary bundle. Otherwise unbundling the temporary bundle will cause a read of the phase cache which has stripped changesets in the cache and that fails. Like with obsmarkers, we unconditionally include the phases in the bundle when stripping (when using bundle2, such as when generaldelta is enabled). The reason for doing that for strip but not for bundle is that strip bundles are not meant to be shared outside the repo, so we don't care as much about compatibility.
2017-06-15 10:15:52 +03:00
bundle2-output-part: "phase-heads" 24 bytes payload
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
adding branch
test: use generaldelta in 'test-rebase-conflict.t' Doing this has some minor impacts on test output since the rebase backup bundle moves to bundle2.
2015-10-20 04:14:36 +03:00
bundle2-input-bundle: with-transaction
bundle2: store changeset count when creating file bundles The bundle2 changegroup part has an advisory param saying how many changesets are in the part. Before this patch, we were setting this part when generating bundle2 parts via the wire protocol but not when generating local bundle2 files. A side effect of not setting the changeset count part is that progress bars don't work when applying changesets. As the tests show, this impacted clone bundles, shelve, backup bundles, `hg unbundle`, and anything touching bundle2 files. This patch adds a backdoor to allow us to pass state from changegroup generation into the unbundler. We store the number of changesets in the changegroup in this state and use it to populate the aforementioned advisory part parameter when generating the bundle2 bundle. I concede that I'm not thrilled by how state is being passed in changegroup.py (it feels a bit hacky). I would love to overhaul the rather confusing set of functions in changegroup.py with something that passes rich objects around instead of e.g. low-level generators. However, given the code freeze for 3.9 is imminent, I'd rather not undertake this endeavor right now. This feels like the easiest way to get the parameter added to the changegroup part.
2016-07-18 01:13:51 +03:00
bundle2-input-part: "changegroup" (params: 1 mandatory 1 advisory) supported
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
adding changesets
add changeset 4c9fbe56a16f
add changeset 19c888675e13
add changeset 2a7f09cac94c
adding manifests
adding file changes
adding f1.txt revisions
added 2 changesets with 2 changes to 1 files
changegroup: skip delta when the underlying revlog do not use them Revlog can now be configured to store full snapshot only. This is used on the changelog. However, the changegroup packing was still recomputing deltas to be sent over the wire. We now just reuse the full snapshot directly in this case, skipping delta computation. This provides use with a large speed up(-30%): # perfchangegroupchangelog on mercurial ! wall 2.010326 comb 2.020000 user 2.000000 sys 0.020000 (best of 5) ! wall 1.382039 comb 1.380000 user 1.370000 sys 0.010000 (best of 8) # perfchangegroupchangelog on pypy ! wall 5.792589 comb 5.780000 user 5.780000 sys 0.000000 (best of 3) ! wall 3.911158 comb 3.920000 user 3.900000 sys 0.020000 (best of 3) # perfchangegroupchangelog on mozilla central ! wall 20.683727 comb 20.680000 user 20.630000 sys 0.050000 (best of 3) ! wall 14.190204 comb 14.190000 user 14.150000 sys 0.040000 (best of 3) Many tests have to be updated because of the change in bundle content. All theses update have been verified. Because diffing changelog was not very valuable, the resulting bundle have similar size (often a bit smaller): # full bundle of mozilla central with delta: 1142740533B without delta: 1142173300B So this is a win all over the board.
2016-10-14 02:31:11 +03:00
bundle2-input-part: total payload size 1686
strip: include phases in bundle (BC) Before this patch, unbundling a stripped changeset would make it a draft (unless the parent was secret). This meant that one would lose phase information when stripping and unbundling secret changesets. The same thing was true for public changesets. While stripping public changesets is generally rare, it's done frequently by e.g. the narrowhg extension. We also include the phases in the temporary bundle, just in case stripping were to fail after that point, so the user can still restore the repo including phase information. Before this patch, the phases were left untouched during the bundling and unbundling of the temporary bundle. Only at the end of the transaction would phasecache.filterunknown() be called to remove phase roots that were no longer valid. We now need to call that also after the first stripping, i.e. before applying the temporary bundle. Otherwise unbundling the temporary bundle will cause a read of the phase cache which has stripped changesets in the cache and that fails. Like with obsmarkers, we unconditionally include the phases in the bundle when stripping (when using bundle2, such as when generaldelta is enabled). The reason for doing that for strip but not for bundle is that strip bundles are not meant to be shared outside the repo, so we don't care as much about compatibility.
2017-06-15 10:15:52 +03:00
bundle2-input-part: "phase-heads" supported
bundle2-input-part: total payload size 24
bundle2-input-bundle: 1 parts total
caches: move the 'updating the branch cache' message in 'updatecaches' We are about to remove the branchmap cache update in changegroup application. There is a debug message alongside this update that we do not want to loose. We move the message beforehand to simplify the test update in the next changeset. The message move is quite noisy and isolating that noise is useful. Most tests update are just line reordering since the message is issued at a later point during the transaction. After this changes, the message is displayed in more case since local commit creation also issue it.
2017-05-02 23:27:44 +03:00
updating the branch cache
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
invalid branchheads cache (served): tip differs
clone: close repo during clone Summary: A future diff will make us depend on repo.close() being called to finalize the writing of some tree data. It turns out we didn't call close on the destination repo during a clone, which caused some tests to change. Let's call close on that repo to prevent a test change in the next diff. Reviewed By: phillco Differential Revision: D8670680 fbshipit-source-id: ad63ccfc51ec4c3de2dad494fdb1ae8f6ba8e40a
2018-06-30 01:37:01 +03:00
history modification detected - truncating revision branch cache to revision 9
rebase: fix selection of base used when rebasing merge (issue4041) Prior this changeset, rebasing a merge whose first parent was not in the rebase lead to wrong and highly conflicting merge. See the in-line comment for details. Test have been updated with the data provided by the reported.
2013-10-30 22:45:14 +04:00
rebase completed
clone: close repo during clone Summary: A future diff will make us depend on repo.close() being called to finalize the writing of some tree data. It turns out we didn't call close on the destination repo during a clone, which caused some tests to change. Let's call close on that repo to prevent a test change in the next diff. Reviewed By: phillco Differential Revision: D8670680 fbshipit-source-id: ad63ccfc51ec4c3de2dad494fdb1ae8f6ba8e40a
2018-06-30 01:37:01 +03:00
truncating cache/rbc-revs-v1 to 72
merge: minimize conflicts when common base is not shown (issue4447) Previously, two changes that were nearly, but not quite, identical would result in large merge conflict regions that looked very similar, and were thus very confusing to users, and lead people used to other source control systems to claim that "mercurial's merge algorithms suck". In the relatively common case of a new file being introduced in two branches with very slight modifications, the old behavior would show the entire file as a conflict, and it would be very difficult for a user to determine what was going on. In the past, mercurial attempted to solve this with a "very smart" algorithm that would find all common lines, but this has significant problems as described in 3d22d20aa950. Instead, we use a "very dumb" algorithm introduced in the previous patch that simply matches lines at the periphery of conflict regions. This minimizes most conflict regions well, though there may still be some degenerate edge cases, like small modification to the beginning and end of a large file.
2016-02-10 20:06:08 +03:00
Test minimization of merge conflicts
$ hg up -q null
$ echo a > a
$ hg add a
$ hg commit -q -m 'a'
$ echo b >> a
$ hg commit -q -m 'ab'
$ hg bookmark ab
$ hg up -q '.^'
$ echo b >> a
$ echo c >> a
$ hg commit -q -m 'abc'
$ hg rebase -s 7bc217434fc1 -d ab --keep
rebasing 13:7bc217434fc1 "abc" (tip)
merging a
warning: conflicts while merging a! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
[1]
$ hg diff
diff -r 328e4ab1f7cc a
--- a/a Thu Jan 01 00:00:00 1970 +0000
+++ b/a * (glob)
@@ -1,2 +1,6 @@
a
b
conflicts: make spacing consistent in conflict markers The way default marker template was defined before this patch, the spacing before dash in conflict markes was dependent on whether changeset is a tip one or not. This is a relevant part of template: '{ifeq(tags, "tip", "", "{tags} "}' If revision is a tip revision with no other tags, this would resolve to an empty string, but for revisions which are not tip and don't have any other tags, this would resolve to a single space string. In the end this causes weirdnesses like the ones you can see in the affected tests. This is a not a big deal, but double spacing may be visually less pleasant. Please note that test changes where commit hashes change are the result of marking files as resolved without removing markers.
2016-11-20 02:41:37 +03:00
+<<<<<<< dest: 328e4ab1f7cc ab - test: ab
merge: minimize conflicts when common base is not shown (issue4447) Previously, two changes that were nearly, but not quite, identical would result in large merge conflict regions that looked very similar, and were thus very confusing to users, and lead people used to other source control systems to claim that "mercurial's merge algorithms suck". In the relatively common case of a new file being introduced in two branches with very slight modifications, the old behavior would show the entire file as a conflict, and it would be very difficult for a user to determine what was going on. In the past, mercurial attempted to solve this with a "very smart" algorithm that would find all common lines, but this has significant problems as described in 3d22d20aa950. Instead, we use a "very dumb" algorithm introduced in the previous patch that simply matches lines at the periphery of conflict regions. This minimizes most conflict regions well, though there may still be some degenerate edge cases, like small modification to the beginning and end of a large file.
2016-02-10 20:06:08 +03:00
+=======
+c
+>>>>>>> source: 7bc217434fc1 - test: abc
$ hg rebase --abort
rebase aborted
$ hg up -q -C 7bc217434fc1
$ hg rebase -s . -d ab --keep -t internal:merge3
rebasing 13:7bc217434fc1 "abc" (tip)
merging a
warning: conflicts while merging a! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
[1]
$ hg diff
diff -r 328e4ab1f7cc a
--- a/a Thu Jan 01 00:00:00 1970 +0000
+++ b/a * (glob)
@@ -1,2 +1,8 @@
a
conflicts: make spacing consistent in conflict markers The way default marker template was defined before this patch, the spacing before dash in conflict markes was dependent on whether changeset is a tip one or not. This is a relevant part of template: '{ifeq(tags, "tip", "", "{tags} "}' If revision is a tip revision with no other tags, this would resolve to an empty string, but for revisions which are not tip and don't have any other tags, this would resolve to a single space string. In the end this causes weirdnesses like the ones you can see in the affected tests. This is a not a big deal, but double spacing may be visually less pleasant. Please note that test changes where commit hashes change are the result of marking files as resolved without removing markers.
2016-11-20 02:41:37 +03:00
+<<<<<<< dest: 328e4ab1f7cc ab - test: ab
merge: minimize conflicts when common base is not shown (issue4447) Previously, two changes that were nearly, but not quite, identical would result in large merge conflict regions that looked very similar, and were thus very confusing to users, and lead people used to other source control systems to claim that "mercurial's merge algorithms suck". In the relatively common case of a new file being introduced in two branches with very slight modifications, the old behavior would show the entire file as a conflict, and it would be very difficult for a user to determine what was going on. In the past, mercurial attempted to solve this with a "very smart" algorithm that would find all common lines, but this has significant problems as described in 3d22d20aa950. Instead, we use a "very dumb" algorithm introduced in the previous patch that simply matches lines at the periphery of conflict regions. This minimizes most conflict regions well, though there may still be some degenerate edge cases, like small modification to the beginning and end of a large file.
2016-02-10 20:06:08 +03:00
b
+||||||| base
+=======
+b
+c
+>>>>>>> source: 7bc217434fc1 - test: abc
test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.
2017-06-24 20:31:41 +03:00
Test rebase with obsstore turned on and off (issue5606)
$ cd $TESTTMP
$ hg init b
$ cd b
$ hg debugdrawdag <<'EOS'
> D
> |
> C
> |
> B E
> |/
> A
> EOS
$ hg update E -q
$ echo 3 > B
$ hg commit --amend -m E -A B -q
config: replace experimental.stabilization by experimental.evolution We replace 'experimental.stabilization=all' by 'experimental.evolution=true' as we will extract individual config in their own config in later patches. Differential Revision: https://phab.mercurial-scm.org/D1148
2017-10-17 12:29:26 +03:00
$ hg rebase -r B+D -d . --config experimental.evolution=true
test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.
2017-06-24 20:31:41 +03:00
rebasing 1:112478962961 "B" (B)
merging B
warning: conflicts while merging B! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
[1]
$ echo 4 > B
$ hg resolve -m
(no more unresolved files)
continue: hg rebase --continue
config: replace experimental.stabilization by experimental.evolution We replace 'experimental.stabilization=all' by 'experimental.evolution=true' as we will extract individual config in their own config in later patches. Differential Revision: https://phab.mercurial-scm.org/D1148
2017-10-17 12:29:26 +03:00
$ hg rebase --continue --config experimental.evolution=none
test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.
2017-06-24 20:31:41 +03:00
rebasing 1:112478962961 "B" (B)
rebasing 3:f585351a92f8 "D" (D)
rebase: use scmutil.cleanupnodes (issue5606) (BC) This patch migrates rebase to use scmutil.cleanupnodes API. It simplifies the code and makes rebase code reusable inside a transaction. This is a BC because the backup file is no longer strip-backup/*-backup.hg, but strip-backup/*-rebase.hg. The latter looks more reasonable since the directory name is "strip-backup" so there is no need to repeat "backup". I think the backup file name change is probably fine as a BC, since we have changed it before (2e51c9a7a08f) and didn't get complains. The end result of this series will be a much more consistent and unified backup names: command | old backup file suffix | new backup file suffix ------------------------------------------------------------------- amend | amend-backup.hg | amend.hg histedit | backup.hg (could be 2 files) | histedit.hg (single file) rebase | backup.hg | rebase.hg strip | backup.hg | backup.hg (note: backup files are under .hg/strip-backup) It also fixes issue5606 as a side effect because the new "delayedstrip" code path will carefully examine nodes (safestriproots) to make sure orphaned changesets won't get stripped by accident. Some warning messages are changed to the new "warning: orphaned descendants detected, not stripping HASHES", which provides more information about exactly what changesets are left behind. Another minor behavior change is when there is an obsoleted changeset with a successor in the destination branch, bookmarks pointing to that obsoleted changeset will not be moved. I have commented in test-rebase-obsolete.t explaining why that is more desirable.
2017-07-08 04:51:46 +03:00
warning: orphaned descendants detected, not stripping 112478962961
tests: remove (glob) annotations that were only for '\' matches # skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
2017-12-11 06:50:57 +03:00
saved backup bundle to $TESTTMP/b/.hg/strip-backup/f585351a92f8-e536a9e4-rebase.hg
test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.
2017-06-24 20:31:41 +03:00
$ rm .hg/localtags
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
$ tglogp
o 5: c5f6f5f52dbd draft 'D'
test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.
2017-06-24 20:31:41 +03:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 4: a8990ee99807 draft 'B'
test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.
2017-06-24 20:31:41 +03:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
@ 3: b2867df0c236 draft 'E'
test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.
2017-06-24 20:31:41 +03:00
|
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
| o 2: 26805aba1e60 draft 'C'
rebase: use scmutil.cleanupnodes (issue5606) (BC) This patch migrates rebase to use scmutil.cleanupnodes API. It simplifies the code and makes rebase code reusable inside a transaction. This is a BC because the backup file is no longer strip-backup/*-backup.hg, but strip-backup/*-rebase.hg. The latter looks more reasonable since the directory name is "strip-backup" so there is no need to repeat "backup". I think the backup file name change is probably fine as a BC, since we have changed it before (2e51c9a7a08f) and didn't get complains. The end result of this series will be a much more consistent and unified backup names: command | old backup file suffix | new backup file suffix ------------------------------------------------------------------- amend | amend-backup.hg | amend.hg histedit | backup.hg (could be 2 files) | histedit.hg (single file) rebase | backup.hg | rebase.hg strip | backup.hg | backup.hg (note: backup files are under .hg/strip-backup) It also fixes issue5606 as a side effect because the new "delayedstrip" code path will carefully examine nodes (safestriproots) to make sure orphaned changesets won't get stripped by accident. Some warning messages are changed to the new "warning: orphaned descendants detected, not stripping HASHES", which provides more information about exactly what changesets are left behind. Another minor behavior change is when there is an obsoleted changeset with a successor in the destination branch, bookmarks pointing to that obsoleted changeset will not be moved. I have commented in test-rebase-obsolete.t explaining why that is more desirable.
2017-07-08 04:51:46 +03:00
| |
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
| o 1: 112478962961 draft 'B'
rebase: use scmutil.cleanupnodes (issue5606) (BC) This patch migrates rebase to use scmutil.cleanupnodes API. It simplifies the code and makes rebase code reusable inside a transaction. This is a BC because the backup file is no longer strip-backup/*-backup.hg, but strip-backup/*-rebase.hg. The latter looks more reasonable since the directory name is "strip-backup" so there is no need to repeat "backup". I think the backup file name change is probably fine as a BC, since we have changed it before (2e51c9a7a08f) and didn't get complains. The end result of this series will be a much more consistent and unified backup names: command | old backup file suffix | new backup file suffix ------------------------------------------------------------------- amend | amend-backup.hg | amend.hg histedit | backup.hg (could be 2 files) | histedit.hg (single file) rebase | backup.hg | rebase.hg strip | backup.hg | backup.hg (note: backup files are under .hg/strip-backup) It also fixes issue5606 as a side effect because the new "delayedstrip" code path will carefully examine nodes (safestriproots) to make sure orphaned changesets won't get stripped by accident. Some warning messages are changed to the new "warning: orphaned descendants detected, not stripping HASHES", which provides more information about exactly what changesets are left behind. Another minor behavior change is when there is an obsoleted changeset with a successor in the destination branch, bookmarks pointing to that obsoleted changeset will not be moved. I have commented in test-rebase-obsolete.t explaining why that is more desirable.
2017-07-08 04:51:46 +03:00
|/
tests: fold tglog into tinit; standardize Summary: Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead. Let's standardize these to reduce the copypasta. It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic. Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`. Reviewed By: quark-zju Differential Revision: D9347072 fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
2018-08-16 20:37:29 +03:00
o 0: 426bada5c675 draft 'A'
test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.
2017-06-24 20:31:41 +03:00
Reference in New Issue Copy Permalink