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

[Victor Suba]

So just caught up on "phases".

It seems to me that "phases" are a component in the solution because it
includes
garbage collection.

If you pull in some divergent heads, say marked with Matt's notation B at 1,
B at 2... and you're
not happy to merge with them you could delete those bookmarks and garbage
collect the dangling
changesets.  The gittish way, since the remotes always have an alias, is if
I remove a remote alias
all it's associated heads can be considered for garbage collection.

Some bookmark namespacing options:
  - Don't allow pulling bookmarks except from repositories in [paths]
  - Create a default alias automatically when pulling from un-pathed URL
(e.g. remote1, remote2,...) the same way "hg clone' makes the "default"
path.

Cheers,
Vic

On Fri, Nov 11, 2011 at 2:19 PM, Sean Farley <sean at mcs.anl.gov> wrote:

> 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://selenic.com/pipermail/mercurial-devel/attachments/20111112/3bbbb0fe/attachment.html>