Meeting notes about remotenames

[Augie Fackler]

On Tue, Mar 10, 2015 at 12:57 PM, Durham Goode <durham at fb.com> 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?)
>
> 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.

Yes, see a later comment of mine somewhere on this thread, where I
muse that maybe the flag not only should exist but should also exist
on push.

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

Right, that all makes sense. I'm a little bummed we can't do it inside
the --bookmark flag somehow.