Meeting notes about remotenames

Augie Fackler raf at durin42.com
Mon Mar 9 22:19:48 UTC 2015


(+TheMystic for commentary)

Sorry for delinquency in responding. Please please don't go running off on your own the three of you building something with bookmarks that we can't embrace as a whole... (your comment about "bike shedding will be ignored" comes across as *actively hostile* to those, like me, who are interested in this topic. Please don't penalize my opinion because of my geography.)

This looks *very* different in worrying ways from what we've previously discussed, and I'd like more context on why you're going for something super super complicated.

On Feb 28, 2015, at 3:51 AM, Ryan McElroy <rm at fb.com> wrote:

> The following are the notes from the meeting Sean, Durham, and I had today concerning the work items for the remote names extension (https://smf.io/hgremotenames). I'm sharing them here mostly to keep the community informed of where we're headed with it. Comments are welcome, but most bikeshedding will be ignored :-D
> 
> A few reference points:
> 
> * http://farley.io/2015/02/new-mercurial-extension-remotenames/
> * http://titanpad.com/hg-remotebookmarks
> Remote Names Extension
> 
> Notes from 2015-02-27 Meeting
> 
> Participants: Sean (smf), Ryan (ryanmce), Durham (durham)
> Defaults
> 
> Everyone feels weakly that we should enable all major features by default for discoverabilty. If there is major push-back on any of the features, we can iterate and turn that feature off.
> Clone Behavior
> 
> For automation, etc, introduce a “--mirror” option for “hg clone” that will act like “hg clone --config remotenames.syncbookmarks=True”

"for automation"? Why can't automation use --config remotenames.syncbookmarks? Is there more story here?

--mirror probably wants to be called --all-bookmarks or something similar.

> Push Behavior
> 
> How should the push command behave under different conditions?
> What if repo has no bookmarks?
> Just disable remotenames
> Hidden heads/closed branch heads
> This was broken with anon head detection; fixed by copying code from “pushdiscovery” function
> Perhaps factor out this code in the future
> No anonymous heads option doesn't seem to be working (can't allow anon heads)
> Fix it and test it
What does this bit mean? I don't understand this.

> Should we have separate flags for different things that -f does today?
> Allows pushing anon heads
> Allows moving remote bookmark anyway
What does this mean?

> (special case of above) allows pushing when local is behind master
> In the end, we decided that keeping everything under --force is fine for now
> Do we want to allow multiple “--to” flags? If so, how to we figure out what rev to push with each?
> For automation, can't we just rely on clone --mirror and push's default behavior to do what we want?
> Maybe we can implement “hg push --to rev:bookmark” if we need to rename local to remote in the future
> Ryan is skeptical that this is needed
What is --to? For renaming a bookmark when we do a push?
> Should remotenames make the default push rev “.” even when --to isn't specified?
> Probably, we all agree this is the right way to go
> Maybe make it configurable
This is backwards incompatible, and makes me sad. Note that '.' isn't a bookmark, so you probably mean something else?
> Should remote names work on the server side to prevent anonymous heads from being pushed?
> No, this should be a client side extension
> Use bundle2 and commit hooks to prevent anonymous heads
> Transition helpers
> 
> These are features to aid groups that are rolling out the remotenames extension into established workflows.

This section existing worries me more than a little. Does this mean that remotenames is hopelessly backwards-incompatible, and therefore won't ever be able to be part of the story of improving bookmarks in core?
> To aid transition to a remote names workflow, on first push or pull after enabling remotenames extension (eg, when creating .hg/remotenames), have a config option to delete local bookmarks that match the name of remote bookmarks
> Potentially have a list of names to be deleted, or perhaps delete all matches
> Hoisting names
> 
> Hoisting refers to the the option to refer to a certain remote's names without the prefix. Eg, remote/master can be referred to as “master” but it will still show up in logs as “remote/master”.
> Name hoisting is a bit of a hack right now, but it works well enough
> No need for short term changes
> Long term, we should get “masking” features into the namespaces API
> Support more generalized versions of hoisting that don't feel hacky
> Renaming remotes
> 
> Remote renaming refers to renaming a path alias. The primary use case is to prevent users from seeing the “default” path in remote names.
> Short term, we should get renaming into the “activepath” function where implicit renaming for default happens now
> Should we keep implicit renaming at all or make it all explicit?
> TBD: format of remote renames?
> [remotenames]
> rename.default = remote
Please consider working with indygreg's path configuration work on this - it seems related.

> Deletion & Renaming
> 
> Currently, there is no way to delete or rename remote bookmarks using the extension. What do we want to support, and how should it work?
> Short term, we want to support “hg push --delete <name>” to delete a remote bookmark
> This should be super cheap — eg, avoid discovery; just delete the bookmark and do nothing else
> How does this interact with anonymous head warnings?
> Should we prevent new anonymous heads if option is on?
> Do we care?
Should this interact with pushing of kill markers for any changes that are referenced by the mark?

> Long term, we might implement “hg push --rename <oldname> --to <newname>” to support atomic bookmark renames
> Behavior and name of “suppressbranches”
> 
> The “suppressbranches” option will hide the remote branch name on a given commit if there is also a remote bookmark pointing to the same commit.
> Functionality is useful in narrow use cases, it's nice to have
> Consider a new name to make it less surprising that it doesn't suppress all remote branches (elidebranches?)
> No need for functionality that suppresses all remote branch heads in extension
> Tracking
> 
> Tracking refers to the git-like feature where a local bookmark can “track” another bookmark (local or remote), which gives some nice default behaviors.

This is very very complicated conceptually. Do we have any sense of how important it is to non-git users? I know there are a handful of git power users that demand this faster horse, but I'd rather it got more careful consideration before we clone the feature wholesale.
> “hg push” with no arguments will default to “hg push --to <tracking>”
> “hg rebase” with no arguments will default to “hg rebase -d <tracking>”
> To set up tracking, we will extend “hg bookmarks” with a “--track” option
> We will record tracking information in a new file, perhaps “bookmarks.tracking”
> Ahead/Behind distance will be stored in a separate cache/file
> Display distance information like git with “hg bookmarks -v” [3 ahead, 2 behind]
> (core) We would like to get “bookmark --update/-U” into core
> Make it possible to create a bookmark and update repo at the same time
> Furthermore, with remotenames, we can also set up tracking in a single command (which will imply --rev)
> Similar to “git co -b <branch> <tracking>”
> Pull Discovery
> 
> How can we leverage remote names to speed up pull discovery?
> Can we speed up pull discovery by starting from remote bookmarks only instead of starting from all heads?
> This would probably help Mozilla repo a lot
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150309/8d2257c1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150309/8d2257c1/attachment.pgp>


More information about the Mercurial-devel mailing list