On 7/29/13 12:49 PM, Ehsan Akhgari wrote:
On 2013-07-29 2:06 PM, Benjamin Smedberg wrote:
Given all the things that we could be doing instead, why is this
important to do now?
I share Benjamin's concern.
Legit concern. Probably low priority. I wanted to have a discussion on
it because I suspect it will be an issue down the road. e.g. it sounds
like things in Git land [1] may force the issue.
Also, before we can discuss this, we need to make sure that every
Mercurial command handles bookmarks sanely. Last I checked, things such
as hg push did not do that (IIRC push just pushes everything on the
named branch you're on by default.)
If you are referring to applied mq patches, if you use [mq] secret=True
(recommended but not the default in Mercurial due to backwards
compatibility), this will set the phase of applied mq patches to
"secret" (as opposed to "draft") which will prevent them from being
pushed. This will muck with try pushes and you'll need an extension to
work around this limitation - something I've been meaning to add to my
new Mercurial extension!
I do concede "push" does have some additional wacky behavior, but it's
mostly around creating new bookmarks/branches/heads. Things also get
much weirder when you start pulling from multiple repos locally, as
Mercurial will try to push all non-remote changesets unless a specific
revision is specified. I created a "pushtree" command [2] in my custom
Mercurial extension to make this more intuitive. But the latter isn't a
concern if the local clone mirrors the single remote.
[1] http://escapewindow.dreamwidth.org/238476.html
[2]
https://hg.mozilla.org/users/gszorc_mozilla.com/hgext-gecko-dev/file/280d1ef3b017/__init__.py#l282
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
