[PATCH] hg: fix _incoming (broken by 72c84f24b420)

[Peter Arrenbrecht]

On Mon, May 2, 2011 at 11:45 AM, Peter Arrenbrecht
<peter.arrenbrecht at gmail.com> wrote:
> On Sun, May 1, 2011 at 6:24 PM, Yuya Nishihara <yuya at tcha.org> wrote:
>> Peter Arrenbrecht wrote:
>>> On Sun, May 1, 2011 at 5:10 PM, Yuya Nishihara <yuya at tcha.org> wrote:
>>> > Peter Arrenbrecht wrote:
>>> >> On Sun, May 1, 2011 at 4:47 PM, Yuya Nishihara <yuya at tcha.org> wrote:
>>> >> > Peter Arrenbrecht wrote:
>>> >> >> # HG changeset patch
>>> >> >> # User Peter Arrenbrecht <peter.arrenbrecht at gmail.com>
>>> >> >> # Date 1304260811 -7200
>>> >> >> # Node ID 04aee572fbf33712ab743bf023dffa66937f642c
>>> >> >> # Parent  72c84f24b420f152ca5cf2d4117de3091e6617e4
>>> >> >> hg: fix _incoming (broken by 72c84f24b420)
>>> >> >>
>>> >> >> diff --git a/mercurial/hg.py b/mercurial/hg.py
>>> >> >> --- a/mercurial/hg.py
>>> >> >> +++ b/mercurial/hg.py
>>> >> >> @@ -433,7 +433,7 @@
>>> >> >>          return subreporecurse()
>>> >> >>
>>> >> >>      try:
>>> >> >> -        chlist = other.changelog.findmissing(common, revs)
>>> >> >> +        chlist = other.changelog.findmissing(common + repo.heads(), revs)
>>> >> >>          displayer = cmdutil.show_changeset(ui, other, opts, buffered)
>>> >> >>
>>> >> >>          # XXX once graphlog extension makes it into core,
>>> >> >
>>> >> > Hi,
>>> >> > I'm just looking this issue.
>>> >> > Isn't it a bug of bundlerepo.getremotechanges() ?
>>> >>
>>> >> I think not. getremotechanges() does the right thing via its call to
>>> >> getbundle(), but _incoming is not acting correctly on its combined
>>> >> local bundlerepo where it has conceptually already pulled the incoming
>>> >> stuff.
>>> >
>>> > Yes, _incoming isn't acting correctly.
>>> > But I think that's because getremotechanges(ui, repo, remote_other, ...)
>>> > returns odd pair, (bundle_other, remote_common, ...).
>>>
>>> You might be right. Given that getremotechanges is undocumented,
>>> however, either of us might be. ;)
>>>
>>> Anyway, it breaks another test (test-branch-option.t), so I'm looking
>>> into it again.
>>
>> Hmm, possibly the case repo.heads() aren't included in other?
>
> Indeed, when other is not a bundlerepo after all. Am rewriting the API
> of getremotechanges completely now to make it clearer and easier for
> clients.

This is superceded by the new patch for getremotechanges I just sent.
-parren