Re: base

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden
> Date: Fri, 27 Aug 2010 22:03:13 +0900
> 
>  > > No, you can provide some representative workflows that are enough
>  > > for you.
> 
>  > Actually, I meant some representative workflows that should cover
>  > the common use-cases.
> 
> By "common use cases" you evidently mean "but not anything that a git
> user might want," or even "that a typical user can express in ordinary
> terms and a git user could achieve by manipulating the DAG" (see below
> for an example).

No, I meant use-cases that are of interest to ordinary users, as
opposed to technicians.

>  >   bzr switch THE_OTHER_BRANCH
> 
> Thank you for playing.  Unfortunately, not only isn't that efficient,
> it doesn't work at all without a fair amount of additional explanation:
> 
>   address@hidden /tmp/test/bar $ bzr switch ../foo
>   bzr: ERROR: Cannot switch a branch, only a checkout.

It is documented to work only with checkouts.

> But it's not clear to me whether the obvious change to that workflow,
> ie, checkout from "../foo" in "bar", actually has the semantics of
> git, though, and I bet you have no idea either.  For example, suppose
> I want to merge two branches in that checkout, but preserve the
> possibility of switching to either of the parents in the future.  This
> is trivial in git: git checkout foo; git merge bar; git branch foo^
> old-foo.  The obvious solution in bzr (bzr checkout -r before:) *does
> not work*; it is not a branch and you cannot commit.

Some combination of "bzr merge -r" with appropriately chosen pair of
revision should be able to do the trick, I think.

> (At least,
> that's what the dox say.)  So I expect I'd have to do a bit more
> preparation to get a usable approximation to git colocated branches.

Why bother, if you can easily branch and work in a separate tree?

>  >   cd A && bzr rebase --onto=revno:-3 ../C
> 
> Thank you for playing.  Unfortunately, this doesn't work in several
> cases.  I could get trunk commits or branch B commits I don't want.

I don't understand what didn't work for you, but it could be due to
bugs in `rebase'.

> Translated to non-DAG terms, the scenario is "just add Miles's feature
> and no extra crap".  To expand a bit (but still use only commonly
> understood development concepts), "I just want Drew's branch with
> Miles's feature.  But I don't want anything in Tom's branch that isn't
> required to implement Miles's feature, I don't want any random work
> done on the trunk since C branched, and I don't want the stuff that
> Drew added to C in his last two commits."
> 
> I think "just add Miles's feature and no extra crap" is a reasonable
> thing to want.  It probably would not occur to you to ask your VCS to
> do it unless you understand the DAG, though.

I see no problems doing what you want with a series of "bzr merge"
commands.  "bzr rebase" is simpler, but if it doesn't work, "merge"
will.

And I don't see any reason to "understand the DAG", either.  What's to
understand, anyway? I know what a DAG is, and I think I have some idea
what "bzr merge" does to a history.  I don't pretend being a
technician, but what I know is enough for what I do.  It was enough to
suggest solution to your riddles, even though I never needed to do any
of that.  So what if some of the solutions have limitations or hit
upon bugs? that's not what this was about.

> 1 out of 3 ain't bad. :-)

You are a darling.