Mercurial > hg
view tests/test-bundle-vs-outgoing.t @ 45883:1817b66897ad
errors: create "similarity hint" for UnknownIdentifier eagerly in constructor
No code wanted to do anything but to produce a hint from it anyway, so
we might as well just store the hint in the exception (which already
extended `Hint`). That way we can easily convert it to a
`ConfigException` when it's parsing of configuration that fails.
I was wondering if the purpose of lazily creating the string was so we
don't create it in cases where it won't get printed anyway. However, I
couldn't find any places where that could happen. If we do find such
places, we could instead revert to making it lazy but add a function
on `UnknownIdentifier` for creating the hint string.
I dropped the comment saying "make sure to check fileset first, as
revset can invoke fileset", which was added in 4e240d6ab898 (dispatch:
offer near-edit-distance suggestions for {file,rev}set functions,
2015-01-26). I couldn't figure out what it meant. The author of that
patch also did not remember the reason for it. Perhaps changes that
have happened since then made it so it no longer matters.
Differential Revision: https://phab.mercurial-scm.org/D9346
author | Martin von Zweigbergk <martinvonz@google.com> |
---|---|
date | Thu, 19 Nov 2020 11:23:59 -0800 |
parents | eb586ed5d8ce |
children |
line wrap: on
line source
this structure seems to tickle a bug in bundle's search for changesets, so first we have to recreate it o 8 | | o 7 | | | o 6 |/| o | 5 | | o | 4 | | | o 3 | | | o 2 |/ o 1 | o 0 $ mkrev() > { > revno=$1 > echo "rev $revno" > echo "rev $revno" > foo.txt > hg -q ci -m"rev $revno" > } setup test repo1 $ hg init repo1 $ cd repo1 $ echo "rev 0" > foo.txt $ hg ci -Am"rev 0" adding foo.txt $ mkrev 1 rev 1 first branch $ mkrev 2 rev 2 $ mkrev 3 rev 3 back to rev 1 to create second branch $ hg up -r1 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ mkrev 4 rev 4 $ mkrev 5 rev 5 merge first branch to second branch $ hg up -C -r5 0 files updated, 0 files merged, 0 files removed, 0 files unresolved $ HGMERGE=internal:local hg merge 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ echo "merge rev 5, rev 3" > foo.txt $ hg ci -m"merge first branch to second branch" one more commit following the merge $ mkrev 7 rev 7 back to "second branch" to make another head $ hg up -r5 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ mkrev 8 rev 8 the story so far $ hg log -G --template "{rev}\n" @ 8 | | o 7 | | | o 6 |/| o | 5 | | o | 4 | | | o 3 | | | o 2 |/ o 1 | o 0 check that "hg outgoing" really does the right thing sanity check of outgoing: expect revs 4 5 6 7 8 $ hg clone -r3 . ../repo2 adding changesets adding manifests adding file changes added 4 changesets with 4 changes to 1 files new changesets 6ae4cca4e39a:478f191e53f8 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved this should (and does) report 5 outgoing revisions: 4 5 6 7 8 $ hg outgoing --template "{rev}\n" ../repo2 comparing with ../repo2 searching for changes 4 5 6 7 8 test bundle (destination repo): expect 5 revisions this should bundle the same 5 revisions that outgoing reported, but it actually bundles 7 $ hg bundle foo.bundle ../repo2 searching for changes 5 changesets found test bundle (base revision): expect 5 revisions this should (and does) give exactly the same result as bundle with a destination repo... i.e. it's wrong too $ hg bundle --base 3 foo.bundle 5 changesets found $ cd ..