Thoughts on remotenames additions to remotebranches

[Pierre-Yves David]

On 01/12/2015 02:28 PM, Mike Hommey wrote:
> On Mon, Jan 12, 2015 at 08:52:15PM +0000, Ryan McElroy wrote:
>> Sean Farley has done a bunch of legwork over the past few weeks to put in some generic namespace infra to mercurial. He now has a 'remotenames' extension (based on remotebranches) that uses this functionality to implement remote bookmarks functionality; check it out at https://smf.io/hgremotenames.
>>
>> The ideas here are pretty exciting and I'm super happy Sean is working in this direction. Below are my high-level thoughts on the extension. Many thanks to Durham Goode and Pierre-Yves David for providing feedback to me and  letting me bounce ideas off of them.
>>
>> (1) There appears to be some nice functionality in the remotebranches extension (such as the upstream() revset), but I don't think remote branches and remote bookmarks should every share a namespace (in this case the "remotenames" namespace). I think combining these ideas makes using each effectively harder. I'm not against the idea of having both functionalities in one extension, per se, but having them share a namespace is the things I'm concerned about here.
>>
>> (2) When remote bookmarks are enabled, I think it makes sense to prevent normal bookmark syncing (h/t Durham).
>> Corollary: (3) How do we push to a particular remote bookmark from a local bookmark?
>> Corollary: (4) How do we delete remote bookmarks?
>>
>> (5) (Sean has mentioned this as well) we need a way to display all bookmarks, local and remote (eg hg bookmarks --all flag)
>>
>> There are a few other small features that Durham thought would be useful as well:
>> * Allowing certain remote bookmarks to always be visible (eg, master/@/trunk remote bookmarks)
>> * Prevent local bookmarks from interfering with remote bookmark names (eg, prevent '/' in bookmark names)
>> * Use bundle2 to prevent race conditions with listkey after pushes
>
> Something else this can be useful for is discovery: it gives you a first
> set of very likely common changesets with the remote repo, instead of
> having to bisect for them.

There is some improvement to discovery durrently in review. I would be 
interrested in some feedback of how it improves thing on your 
pathological repository before doing anything more complicated.

-- 
Pierre-Yves David