D937: remotenames: move function to pull remotenames from the remoterepo to core
sean at farley.io
Wed Nov 1 15:20:59 EDT 2017
pulkit (Pulkit Goyal) <phabricator at mercurial-scm.org> writes:
> pulkit created this revision.
> Herald added a subscriber: mercurial-devel.
> Herald added a reviewer: hg-reviewers.
> REVISION SUMMARY
> This patch moves the functionality to pull branches and bookmarks from a
> server from which we are pulling to core. The function used to exist in
> remotenames repo.
Bringing all of remotenames into core is a slippery slope to a confusing
user experience. As a whole it’s unnecessarily complicated. I recommend
splitting remotenames up and only bringing in parts (1) & (2) (below) that
were discussed at the Montreal sprint.
The current remotenames code is composed of roughly three layers:
1) the base layer: bugfixes and storage format
2) the remote tracking layer: simple wrappers that sit in-between push /
pull and write out the remote info
3) behavior changes: push and pull changes, --anon, update -B, etc.
(1) and (2) were previously discussed in Montreal and were ok’d by Matt.
For (1), most of these patches are suitable for core. It’s bugfixes and
refactoring to help all extensions. There are a number of things to
The easiest to start tackling would be schemes:
Next, there is strengthening path logic (perhaps refactoring a bit) so
that working with paths is less fragile and error-prone (e.g. see
activepath function). Fixing this in core will benefit all extensions.
Third, there is a long-standing issue with multiple extensions
displaying bookmarks. I’ve done some refactoring in core to help with
this issue but there is still work to be done. In remotenames, you can
see how much copy-pasta there is in displaylocalbookmarks and
exbookmarks. Currently, this breaks with any other extension that also
tries to display bookmarks (e.g. hg-git).
Lastly, for (1), there is the issue with storage format selection. We
have many storage formats in Mercurial, and we should put some thought
into the remotenames’ format. I hesitate to use json because bookmarks
can be unicode.
There is a lot of work to be done for (1). I have recommendations for
(2) that I can address in a follow-up, if desired. I hope this
illustrates how much work needs to be done for (1) and why we should
reconsider this approach submitted so far.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the Mercurial-devel