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

[Victor Suba]

Timeless, I think that's one way to do it sure.  It does place more onus on
me the user to play safe instead of the tool playing safe for me.

Making extra clones has other disadvantages that have been well discussed
before, and I think are the reason people keep trying to fix it (bookmark,
lbranch, ...)

So, Mercurial is in a way growing more complex than (dare I say it) Git
already
since Git only has one branch model for the user to learn.

I'm not going to gid myself that Hg can and will make complicated behavior
changes
that would alienate current users though.

Cheers,
Vic

On Fri, Nov 11, 2011 at 5:35 AM, timeless <timeless at gmail.com> wrote:

> Please consider Phases instead of this complicated Behavior Change.
>
> Your argument seems to partially be of the form "I want to be able to
> have wanton sex for the experiences and not risk infecting my spouse."
> Thankfully, in computing space this is possible. In Hg, you do this:
>
> hg clone http://spouse/repo workspace
> # incoming is spouse
> hg clone workspace playspace
> # incoming is workspace
> cd playspace
> # play
> hg pull http://random/space
> hg pull http://another/space
> hg pull -R ../workspace
> # pull from spouse to workspace
> hg pull
> # transitive pull from spouse+workspace into playspace
>
> You don't arbitrarily hg push from playspace to workspace, that would
> be reckless. And you certainly don't push from workspace to spouse
> without reviewing, that would be grouns for divorce.
>
> Phases will give you some of the mutability you want. Things which
> aren't for publishing won't be pushed to public servers.
>
>
> On 11/11/11, Victor Suba <vosuba at gmail.com> wrote:
> > Hi Arne,
> >
> >>> Git will fetch everything unless you explicitly tell it to fetch only a
> >>> specific branch,
> >>> so there's no risk of not having every branch from the remote when you
> go
> >>> offline.
> >
> >> So what you meant is that you don’t want multistep pulling?
> >> If I don’t pull the head explicitely, the next who pulls from me does
> not
> > get
> >> it?
> >
> > Right, I mean I don't think you have to explicitly pull each head if
> there
> > is a mechanism
> > for specifying what should be automatic and what not, but think it is
> > beneficial to have
> > control over change propagation.  I don't want to be responsible for
> > everything I might
> > pull from someone else - especially since in base Hg deleting history is
> > not default behavior.
> >
> > If I pull everything I'm liable to get something broken that I don't even
> > care about and
> > will never test, then I might inadvertently push that upstream or someone
> > else pull from me.
> >
> > Or, I pull a fork from someone else, test it and find out that it doesn't
> > work so I
> > don't want to merge it with my head, but now "hg push" will moan at me
> for
> > pushing multiple new heads - my resolution is I have to use "hg push rev"
> > explicitly
> > from now until the fork is fixed - which means waiting for the originator
> > to fix it or
> > pulling the knife out ("strip").
> >
> > Cheers,
> > Vic
> >
> > On Thu, Nov 10, 2011 at 10:23 PM, Arne Babenhauserheide
> > <arne_bab at web.de>wrote:
> >
> >> Am Donnerstag, 10. November 2011, 16:15:35 schrieb Victor Suba:
> >> > Git will fetch everything unless you explicitly tell it to fetch only
> a
> >> > specific branch,
> >> > so there's no risk of not having every branch from the remote when you
> >> > go
> >> > offline.
> >>
> >> So what you meant is that you don’t want multistep pulling?
> >> If I don’t pull the head explicitely, the next who pulls from me does
> not
> >> get
> >> it?
> >>
> >> (trying to understand your post)
> >>
> >> Best wishes,
> >> Arne
> >
>
> --
> Sent from my mobile device
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111111/3a485f07/attachment.html>