Meeting notes about remotenames

[Ryan McElroy]

On 3/9/2015 3:19 PM, Augie Fackler wrote:
> (+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 
> <mailto: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?
>>       o Just disable remotenames
>>   * Hidden heads/closed branch heads
>>       o 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)
>>       o 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?
>>       o Allows pushing anon heads
>>       o Allows moving remote bookmark anyway
>>
> What does this mean?
>
>>       o (special case of above) allows pushing when local is behind
>>         master
>>       o 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?
>>       o For automation, can't we just rely on clone --mirror and
>>         push's default behavior to do what we want?
>>       o 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?
>>       o Probably, we all agree this is the right way to go
>>       o 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?
>>       o No, this should be a client side extension
>>       o 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
>>       o No need for short term changes
>>   * Long term, we should get “masking” features into the namespaces API
>>       o 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
>>       o 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
>>       o This should be super cheap — eg, avoid discovery; just delete
>>         the bookmark and do nothing else
>>       o 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”
>>       o Ahead/Behind distance will be stored in a separate cache/file
>>       o Display distance information like git with “hg bookmarks -v”
>>         [3 ahead, 2 behind]
>>   * (core) We would like to get “bookmark --update/-U” into core
>>       o Make it possible to create a bookmark and update repo at the
>>         same time
>>       o Furthermore, with remotenames, we can also set up tracking in
>>         a single command (which will imply --rev)
>>       o 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?
>>       o This would probably help Mozilla repo a lot
>>
>>

Apologies for coming across as actively hostile. I wanted to avoid 
things like "I don't like the name of X". I'm actually open to being 
convinced by good arguments that certain things are a bad direction. For 
example, Pierre-Yves did a good job of talking to me about why adding a 
-U flag to bookmarks might be a bad idea -- because of, for example, the 
explosion in options due to the cross-product of possible options 
between both bookmarks and update options (eg, if there's a --update, 
does that imply we need a --check and --clean as well?) So that's where 
I'm coming from, and again apologies for coming across as hostile.

I'm still looking forward to feedback on these ideas and directions.

~Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150309/0a846469/attachment.html>