Meeting notes about remotenames

[Ryan McElroy]

On 3/10/2015 9:57 AM, Durham Goode wrote:
>
> 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 fb.com 
>>>>> <mailto:rm at fb.com>>
>>>>> 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?)

I thought Sean put a good warning into the README file, but we can 
iterate on this if there's specific language you'd like to see. It's 
also version 0.2 right now, so hopefully that's a good indication that 
it's under early-stage active development. Once we figure out what 
concepts actually work well and what doesn't, we can clean up and strip 
out less useful stuff and prepare the good parts for inclusion in core, 
where its UI/API will become a lot more locked down.

> 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 rebasing).

I'd also add that, coming from a git background, I thought I needed 
bookmarks everywhere "important". But having used remotenames for a 
while, I've found I don't feel the need for bookmarks much anymore 
(since I'll never accidentally move a "server-side" bookmark). I might 
use bookmarks more, but half of my workflow commands broke my git-branch 
based bookmarks workflow (eg, hg push multiple revs with hg-subversion, 
some evolve commands, etc), so it's usually easier just to forego 
bookmarks altogether.

That being said, I'm all for actually fixing bookmarks is all these 
cases, this is just where I've found myself recently after using the 
extension for a while.