<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">And what is the rationale for that? That -also- seems obviously wrong.</div>

</div></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see: the rationale is it saves transmit time for the edge case of<br>


"pushing changeset that are already present but secret on target".<br>
<br>
That's a fairly contrived scenario, and a poor reason to make this<br>
design choice. And it's almost certainly going to cause trouble.<br>
People today do things like 'hg id -r tip remote' to figure out what<br>
their incoming changeset group is going to look like, and if we don't<br>
actively hide these changesets from remote clients, we're breaking that.<br>
Similarly, if discovery says there are remote csets and we get an empty<br>
changegroup, we're going to upset people using 'hg summary --remote'.<br>
<br>
If we have to resend changesets because they happen to exist but are<br>
secret remotely, then I'm absolutely fine with that if it means we can<br>
have them actually be properly isolated.</blockquote><div><br></div><div>Ah, ok, I finally get it now. I agree about not sharing the 'private / secret / local' csets, but if that's the case, then what exactly is ambiguous with using 'local' as the name? Unless you mean it clashes with 'local repo' naming?</div>

</div>