On 2013-07-29 4:07 PM, Gregory Szorc wrote:
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.
Not sure what that has to do with the Mercurial discussion. The reason
why I did that and why RelEng is doing this is that this is the Git Way
of doing things. That is not the case with Mercurial.
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.
My main concern was that somebody should go and investigate that the
right thing happens for all commands if the hg user has never used
bookmarks before (which are a rather recent addition to hg.)
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
