[PATCH 4 of 4 RFC path options] ui: add a "pushnames" path option
Gregory Szorc
gregory.szorc at gmail.com
Sun Mar 15 00:02:14 CDT 2015
On Sat, Mar 14, 2015 at 12:38 AM, Ryan McElroy <rm at fb.com> wrote:
> On 3/3/2015 11:39 AM, Augie Fackler wrote:
>
>> On Sun, Mar 01, 2015 at 03:23:48PM -0800, Gregory Szorc wrote:
>>
>>> # HG changeset patch
>>> # User Gregory Szorc <gregory.szorc at gmail.com>
>>> # Date 1423550715 28800
>>> # Mon Feb 09 22:45:15 2015 -0800
>>> # Node ID 96836adc7bfd1a1b41befc2cbbcc135fc35b7948
>>> # Parent 4da24a2a9e7b82e5cd0082e4d69255c0cd5b805b
>>> ui: add a "pushnames" path option
>>>
>> I think I'm +0 on this in principle, but we should probably coordinate
>> between this and the workflow ideas smf and Ryan have around
>> remotenames. I haven't done enough thinking to have strong convictions
>> yet.
>>
>
> Gregory, have you played around with the latest remotenames extension?
> There's this interesting/controversial/etc "feature" called tracking,
> inspired by git, where a bookmark can "track" another name (usually a
> remote bookmark, but could also be local, or other names exposed via the
> namespace API), so that a few commands just "do the right thing" when
> called without parameters:
>
> "hg rebase" rebases with an implicit "--dest <tracking name>"
> "hg push" pushes with an implicit "dest" path and updates an implicit
> "--to" bookmark
>
> Today, while chatting with smf, I realized we can go one step further and
> allow the push tracking to be different from the rebase tracking. This idea
> was inspired by the workflow Sean and I have adopted:
>
> sean's laptop ---(push)---> smf.io ---(pull)--> ryan's devserver
> ---(push)---> "nexus" (hg.silverfir.net) ---(pull)---> sean's laptop ...
>
> In this world, on my devserver, I want to rebase onto the changes from
> smf.io's @ bookmark, but I want to push to nexus and the @ bookmark
> there. If we have two tracking targets, we can do this. I'm not convinced
> this is a good idea yet, since it seems too complicated, but we're in
> exploratory mode here so I might implement this at some point.
>
> Anyway, back to this patch: I think it's useful -- it's essentially moving
> command-line options into config to avoid repeated typing and potential
> mistakes, which makes me think this is good, but it also isn't a
> fundamentally different workflow, like remotenames is attempting to unlock
> (eg the --to flag on push allows pushing to a remote bookmark without the
> same bookmark -- or any bookmark for that matter -- being present in the
> local repo for that rev).
>
> I'd call it 'pushbookmark' and restrict to to the equivalent of passing -B
> <name> to hg push. The other stuff can come later when it becomes more
> clear what direction we want to go.
>
Yes, I've been following the remotenames extension and discussions with
extreme interest. I'm even a user!
I think I already said that I would drop this patch from the eventual
non-RFC series because it is unclear how it will interact with remotenames
and it would be best to have a better story before adding this feature to
core.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150314/76531080/attachment.html>
More information about the Mercurial-devel
mailing list