Thoughts on remotenames additions to remotebranches

Mike Hommey mh at glandium.org
Mon Jan 12 16:28:56 CST 2015


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.

Mike


More information about the Mercurial-devel mailing list