[PATCH 2 of 4] clone to master bookmark if available

[Sean Farley]

>
> As for alienating people, please note that I'm not part of crew, I'm
> mostly a user.
>
> In mercurial, there's by default a rule to prevent pushing where it
> creates a state with multiple heads. There's an expectation that you
> push complete work merged with the previous completed work.
>

Then what does a developer do when they need help? Also, there is a
"working" state that compiles but isn't feature complete (so some would say
it is "broken", bah).


> Mercurial's methodology wants your real commits to be good commits. If
> they're bad commits and they break things then later on in time the
> merge algorithm can easily make bad decisions based on your commit, as
> can any human who doesn't have perfect memory of your commits.
>

I completely agree.


> As for branching mechanisms, yes, mercurial has a bunch, there are
> even wiki pages to help...
> http://mercurial.selenic.com/wiki/Branch
> This one is probably more relevant:
> http://mercurial.selenic.com/wiki/BranchingExplained
>
> There's no handy page in the wiki for BehaviorChange, but
> http://mercurial.selenic.com/wiki/CompatibilityRules is the one that
> matters.
>
> Making hg merge behave *differently* than expected is problematic. I'm
> not sure that your proposal would, but I think it's safe for me to
> expect you to provide a before/after table.


I also agree with this and don't want to change (much) default behavior.
Especially in merge.

Perhaps you're only
> changing cases that today would fail with "multiple heads, please
> specify".


Yes! I am talking about multiple heads that are bookmarked, as per my
previous email:

http://selenic.com/pipermail/mercurial/2011-October/040607.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20111111/9918c232/attachment-0002.html>