Meeting notes about remotenames

Augie Fackler raf at
Tue Mar 10 09:40:28 CDT 2015

On Mon, Mar 09, 2015 at 05:25:35PM -0700, Ryan McElroy wrote:
> On 3/9/2015 4:53 PM, Ryan McElroy wrote:
> >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 <mailto:rm at>>
> >>wrote:
> >>
> >>>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.
> I'm happy with this name change. I actually argued that for automation,
> --config would be fine to use, but I was convinced that for discountability,
> it would be worth having an option added to clone itself. Actually, now that
> you've called it out, what do you think about "hg clone --bookmarks/-B"?

--bookmarks seems reasonable. I'm not sure it merits spending -B from
our short-flag arsenal, but we can bikeshed that later when we've
figured out what we want upstream. This reinforces my belief that we
need to do some Serious Work around discoverability of config knobs. Sigh.

(As an aside, we should probably have some kind of note on remotenames
that it's intentionally a functionality sandbox and that we're
probably going to make breaking changes semi-regularly until we know
what we want?)

> >>
> >>>    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.
> There's a bug in the current version of the extension -- it was supposed to
> allow anonymous heads with an option, but that option wasn't working because
> of a bug and lack of testing. I'm going to fix it so the option actually
> works, and add a test so it doesn't regress.

Ah, okay. If I had to guess, this feature will just be too annoying to
make the cut.

> >>
> >>>  * 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?
> Currently, the --force flag allows a lot of different behaviors in push with
> this extension. This is also a typo -- it should read "allows moving remote
> bookmark anywhere" instead of "anyway". A non-force "hg push --to" allows
> only a linear move forward of a bookmark (eg, directly related descendant).

Ah, interesting. Does push --to respect obsolete markers?

> >>
> >>>      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?
> Currently, --to takes the rev being pushed and attached a bookmark to it on
> the remote end, regardless if there is a local bookmark

Aaaaah! So you can leave something not named locally, but name it on
the remote side. Cute. Might be handy for code review tooling some day.

> >>>  * 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?
> It looks like Greg Szorc's paths-to-classes stuff will already provide us
> with a way to do this, so the default here is less important. That being
> said, I've never actually wanted the default push behavior once, but I come
> from a git-centric background so maybe that's just me being confused (after
> using mercurial from 2007-2009, I used git from 2009-2014 before trying
> mercurial again)

I don't actually use bare 'hg push' at all either, but the current
default is (sadly) the default, so the best we can do is put this in a
knob (ui.requirepushrev or something perhaps). I'd endorse that as
part of my still-vaporware friendlyhg idea (I just made a wikipage for
that, btw:, as it
seems like once you're on the bookmarks workflow bandwagon (which
seems to be getting more popular) bare 'hg push' is pretty much never

That makes me wonder if we shouldn't have a --everything flag on
push/pull that's symmetric, rather than calling it just --bookmarks or
--all-bookmarks. (Thinking of the use case where I would use a
non-publishing server rather than unison to synchronize my working

> >>>  * 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?
> I don't think so -- let's say you have an existing clone, and you turn on
> remotebookmarks. How should that compare to the behavior of having a new
> clone with remotebookmarks already enabled? Most of the stuff here is about
> easing that "transition" -- especially at scale. As a specific example, at
> Facebook we're using a bookmark called "master" for mainline development,
> and a new clone would not have this (it would be the default path's "master"
> bookmark instead). This allows us to ensure that when this get turned on to
> thousands of engineers, the old and new workflows work the same.

Ah, gotcha, this is similar to some stuff we talked about (I think we
called them "Virutal Bookmarks" then) at the sprint to tiptoe around
BC problems.

> >>
> >>>    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?
> I don't know what a kill marker is, so I'm not sure about this one.

Obsolete markers that mark a change as obsolete without a
successor. Basically, I'm wondering what the behavior should be if you
do 'hg push --delete foobar', and there were changes in
'only(foobar)'. I don't have an answer.

> >>
> >>>  * 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.
> I'd argue that tracking can make workflows easier. Today, I'm still confused
> when I run "hg rebase" or "hg push" (not to mention "hg push") without
> arguments. This makes it possible for these commands to do the right thing.
> Furthermore, it's totally optionally, and will be cofigurable via an option
> (as are almost all other pieces of this extension so far).

Hm, okay. Ideally, I think our solution here probably needs to do two things:

1) Avoid, if at all possible, git jargon unless our behavior exactly
matches git jargon

2) Be simple enough that there's a fairly gentle onramp to the more
complex bits of functionality.

I don't understand git's tracking business pretty much at all, so I'm
happy to be a canary for 2 if you need one.


This is getting long enough maybe we should have a
BookmarksEnhancementsPlan page or something outlining the things we
want to do and some justification as to why, so we can subscribe to
the page and have a longer-lasting discussion that way.

> >
> >~Ryan

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at

More information about the Mercurial-devel mailing list