Meeting notes about remotenames

Tue Mar 10 11:26:35 CDT 2015

On Tue, Mar 10, 2015 at 3:40 PM, Augie Fackler <raf at durin42.com> 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?)
>
>>
>> >>
>> >>>    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: http://mercurial.selenic.com/wiki/FriendlyHGPlan), 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
> useful.

FWIW, where I work, after a few mistakes related to people pushing
things that they did not intend to push, we changed our internal
mercurial configuration file (which is automatically deployed to all
our TortoiseHg users) so that TortoiseHg's defaultpush setting is set
to "revision" (as opposed to "all"). This makes the TortoiseHg push
button do a "push -r ." by default.

Cheers,

Angel