Re: base

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

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

Sure, but what about the case of "I want this feature, but no other
crap"?  Why wouldn't that be of interest to an ordinary user?  In git,
that's simple to express:

    git rebase --onto my-branch feature-parent feature-branch

You do need to know which branch is feature-parent, but gitk will tell
you that with "gitk --all".  You only need to be able to see the green
tags in gitk, and trace your branch of interest back to its node and
up again to a tag (and any such tag will do -- although it requires
some understanding of DAGs to know *why*, this means it's hard for a
naive user to make a mistake here).  So doing this is not beyond an
ambitious but non-technical user at all.  *Explaining how* to do it,
though, requires some knowledge.

The point of this whole subthread is that the git model makes this
easy (for the technician) to think about.  It is not easy to think
about this in bzr, and harder to implement.  You wave your hands and
say "I'm sure it can be done with merge".  Well, I'm pretty sure too,
but I'm also sure I'd have to ask Robert Collins to tell me how.

 > Why bother [with colocated branches], if you can easily branch and
 > work in a separate tree?

Because I *don't like* working in a separate tree for *some* purposes,
although I readily create separate workspaces (in git) for others.
Why should power users have to put up with these limitations?

 > And I don't see any reason to "understand the DAG", either.  What's
 > to understand, anyway?

It's not a big deal to "understand the DAG," of course.  You can just
see it with the appropriate tool (and all VCSes supply such a tool).
What's useful is to understand how user-level concepts like "features"
map to the DAG, and how your VCS can manipulate DAG parts that (may or
may not) correspond to user-level features.

 > I know what a DAG is, and I think I have some idea what "bzr merge"
 > does to a history.

Oh?  Suppose that branch foo has 4 revisions and branch bar has only
the first one.  Now do "bzr merge -r2..4 ../foo; bzr commit -m merge"
in branch bar.  What does "bzr log -n0" show?  I was surprised (and
disappointed, although I understand why it happened once I saw the
result).

#! /bin/bash
pushd /tmp; mkdir test; cd test
mkdir foo; cd foo; bzr init
addfile () { echo $1 > $1; bzr add $1; bzr commit -m "add $1"; }
addfile foo
bzr branch . ../bar
addfile bar
addfile baz
addfile quux
cd ../bar
bzr merge -r2..4 ../foo; bzr commit -m merge
bzr log -n0

Did you predict the output correctly?