[PATCH 1 of 2 RFC RESEND] bookmarks: allow push to create a new remote head if it is about to be bookmarked via -B

Kevin Bullock kbullock+mercurial at ringworld.org
Sat Sep 21 22:51:21 CDT 2013


On 8 Sep 2013, at 5:45 AM, Stephen Lee wrote:

> # HG changeset patch
> # User Stephen Lee <sphen.lee at gmail.com>
> # Date 1378636805 -36000
> # Node ID 4f3b94d13ecd9d35b1c7bd65e57f8700322d2816
> # Parent  1d07bf106c2ad1c7ef5e257e754ca8d858bd04b0
> bookmarks: allow push to create a new remote head if it is about to be bookmarked via -B
> 
> Push is currently allowed to create a new head if there is a remote bookmark that will
> be updated to point to the new head.  If the bookmark is not known remotely then
> push aborts, even if a -B argument is about to push the bookmark. This change allows
> push to continue in this case.  This does not require a wireproto force.
> 
> This is an RFC change.  The list of new bookmarks is stored in config to avoid changing
> the signature of localrepo.push which is wrapped by many extensions (both bundled and external).
> A real solution would need to find a cleaner way to do this.

Changing the signature of localrepo.push is fine across major releases. I'd like to see us do this the right way. I'm now convinced that it can be done while minimizing the chance for clobberage.

But! I think to do anything without driving ourselves completely mad in code, we have to get to that bookmarks-exchange refactoring that we've so badly needed. We already have a problem where we can push a bookmark once in localrepo.push and again in commands.py (if you push a bookmark with -B that already exists remotely, IIRC).

Thanks for your patience and perseverence on this. Maybe some combination of you, Augie, Sean, and I can work a bit more synchronously on a plan to attack this soon?

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock



More information about the Mercurial-devel mailing list