as highlighted by this test patch diff --git a/tests/test-obsolete.t b/tests/test-obsolete.t --- a/tests/test-obsolete.t +++ b/tests/test-obsolete.t @@ -774,6 +774,41 @@ Checking _enable=False warning if obsole parent: 7:50c51b361e60 user: test date: Thu Jan 01 00:00:00 1970 +0000 summary: add celestine + $ echo '[extensions]' >> $HGRCPATH + $ echo "obs=${TESTTMP}/obs.py" >> $HGRCPATH + #endif + +Test incoming/oucoming with changeset obsolete remotly, known locally + + $ hg init repo-issue3805 + $ cd repo-issue3805 + $ echo "foo" > foo + $ hg ci -Am "A" + adding foo + $ hg log -G + @ changeset: 0:193e9254ce7e + tag: tip + user: test + date: Thu Jan 01 00:00:00 1970 +0000 + summary: A + + $ hg clone . ../other-issue3805 + updating to branch default + 1 files updated, 0 files merged, 0 files removed, 0 files unresolved + $ echo "bar" >> foo + $ hg ci --amend + $ cd ../other-issue3805 + $ hg incoming --traceback + comparing with $TESTTMP/tmpe/repo-issue3805 + searching for changes + abort: 00changelog.i@193e9254ce7e: no node! + [255] + $ hg outgoing + comparing with $TESTTMP/tmpe/repo-issue3805 + searching for changes + no changes found + [1] +
it used to work before, updating to urgent.
This affect incoming from local repo only. Fix mostly ready.
Fixed by http://selenic.com/repo/hg/rev/cd403d6d96ef Pierre-Yves David <pierre-yves.david@ens-lyon.org> incoming: fix incoming when a local head is remotely filtered (issue3805) In its current state discovery may return (remotely) filtered elements in "common". This has usually no impact as "missing" is kept clear of filtered elements. However when the "remote" repo is a local repo (disk accessible, and directly created in memory) the incoming code takes a shortcut and directly uses the "remote" repo to generate the incoming output. When some common elements are filtered this led to a crash. We now ensure we use an unfiltered repository to generate the incoming output. This does not change the behavior as missing is clear of filtered revision. Now that we have proper low level filtering, incoming code needs a deeper cleanup but it is already planned. (please test the fix)
When I try the test case with hg 2.5.1, 'hg incoming --traceback' after the 'hg ci --amend' in the second repo gives 'abort: repository is unrelated': comparing with /tmp/3805/repo-issue3805 searching for changes Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 88, in _runcatch return _dispatch(req) File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 743, in _dispatch cmdpats, cmdoptions) File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 514, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 833, in _runcommand return checkargs() File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 804, in checkargs return cmdfunc() File "/usr/local/lib/python2.7/site-packages/mercurial/dispatch.py", line 740, in <lambda> d = lambda: util.checksignature(func)(ui, *args, **cmdoptions) File "/usr/local/lib/python2.7/site-packages/mercurial/util.py", line 475, in check return func(*args, **kwargs) File "/usr/local/lib/python2.7/site-packages/mercurial/commands.py", line 4019, in incoming return hg.incoming(ui, repo, source, opts) File "/usr/local/lib/python2.7/site-packages/mercurial/hg.py", line 547, in incoming return _incoming(display, subreporecurse, ui, repo, source, opts) File "/usr/local/lib/python2.7/site-packages/mercurial/hg.py", line 506, in _incoming revs, opts["bundle"], opts["force"]) File "/usr/local/lib/python2.7/site-packages/mercurial/bundlerepo.py", line 336, in getremotechanges force=force) File "/usr/local/lib/python2.7/site-packages/mercurial/discovery.py", line 46, in findcommonincoming abortwhenunrelated=not force) File "/usr/local/lib/python2.7/site-packages/mercurial/setdiscovery.py", line 191, in findcommonheads raise util.Abort(_("repository is unrelated")) Abort: repository is unrelated abort: repository is unrelated
Mercurial decides repositories are related if their first commit is the same. If you obsolete the first commit such that it's not available to remote clients, getting this error is a correct result.