Re: base

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > From: "Stephen J. Turnbull" <address@hidden>
 > > Cc: Miles Bader <address@hidden>,
 > >     address@hidden
 > > Date: Thu, 26 Aug 2010 20:01:02 +0900
 > > 
 > > Eli Zaretskii writes:
 > > 
 > >  > You are pushing a simple request ad absurdum.  I wasn't asking
 > >  > for an exhaustive list of _all_possible_ workflows, only for a
 > >  > few representative ones.  And please don't tell me that's
 > >  > impossible, or even hard, because today I can easily do that
 > >  > for Bazaar.
 > > 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).

 > > That's far from providing representative workflows that would be
 > > enough to convince anyone who has actually used git that bzr is a
 > > half-adequate replacement.

 > Indeed, I see no reason to ask for workflows that convince not to
 > use bzr in a project that uses bzr.

Lack of some workflows I use frequently in git is certainly the most
important reason why I avoid bzr.  It will certainly inhibit me from
contributing code to Emacs in the near to medium term.  Maybe you
think that is a good thing?

 > > For example, suppose I ask, "How do I efficiently switch from one
 > > branch to another in the same directory, like I do in git?"
 > 
 >   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.

Obviously I just used ordinary branches to get that error.

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.  (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.

 > > Or "how do I rebase branch A from the common ancestor with branch
 > > B to the grandparent of the head of branch C, which branched from
 > > trunk before B did?"
 > 
 >   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.

So, what was that all about?

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 don't think it's reasonable to ask anybody to explain how to achieve
that result based on a few memorized workflows, and without reference
to the DAG.  However, the DAG-based description, and its git
implementation should give me a close approximation to what I really
want.  The git implementation is straightforward:

    git rebase --onto C~2 B A

(or "git checkout A; git rebase --onto C~2 B").

 > Note that the acronym DAG is not used anywhere.

OK, you got me on that one.  1 out of 3 ain't bad. :-)