Meeting notes about remotenames

Durham Goode durham at
Tue Mar 10 11:57:59 CDT 2015

On 3/10/15 7:40 AM, Augie Fackler wrote:
> 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?)
Mirror is nice because it matches the user intention in many cases. Like 
in automation, we often want an exact replica of a repo, not a 'peer'.  
--mirror would allow us to put non-bookmark related logic under the same 
--mirror umbrella for such a use case.  Though I don't feel strongly 
enough to argue for it.
>>>>>       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.
Our common use case is the user has a local bookmark whose name differs 
from the remote, and this allows them to push it without renaming it 
first.  This will also be used for our new ability to let the server do 
the rebasing for you (--to lets the server know where it should be 

More information about the Mercurial-devel mailing list