Call for discussion: Phase names

[Pierre-Yves David]

On Tue, Jan 10, 2012 at 11:40:01AM -0600, Kevin Bullock wrote:
> On Jan 10, 2012, at 11:19 AM, Pierre-Yves David wrote:
> 
> > On Tue, Jan 10, 2012 at 10:55:06AM -0600, Kevin Bullock wrote:
> >> On Jan 9, 2012, at 7:01 PM, Pierre-Yves David wrote:
> >> 
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>> 
> >>> 
> >>> On 9 janv. 2012, at 23:25, Matt Mackall wrote:
> >>> 
> >>> People today do things like 'hg id -r tip remote' to figure out what
> >>>> their incoming changeset group is going to look like, and if we don't
> >>>> actively hide these changesets from remote clients, we're breaking that.
> >>> 
> >>> Those people should use incoming…
> >> 
> >> ?!? incoming fetches a full bundle. There are plenty of cases where you want to just see if a remote has a given cset (or what cset it thinks a given label points to), without the overhead of actually fetching changes.
> > 
> > Remote lookup is currently not being rewritten according secret. This could be
> > seen as a bug but I'm not enthousiasmed by the fact that the following commands
> > return different thing
> > 
> >    hg id -r <some-lookup> repo
> >    hg -R repo id -r <some-lookup>
> > 
> > (with some-lookup any of tip, <branch-name>, <bookmarks>, …)
> 
> I don't see any reason why those would have to be different if we leave
> secret changes out of discovery. Either command should end up with an
> instance of localrepo if the repo is local, and bypass the discovery code
> anyway, shouldn't it? (I ask naïvely, having never actually looked at that
> part of the code.)

With you behavior you describe above, you have an inconsistency between the
what `hg -r tip <remote>` says and `hg pull <remote>` fetch. This inconcistency
was the initial point of this discussion…

raise RecursiveDiscussionError


-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20120110/c19ba267/attachment.asc>