Re: base

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

Eli Zaretskii writes:

 > > user?  In git, that's simple to express:
 > > 
 > >     git rebase --onto my-branch feature-parent feature-branch
 > 
 > In bzr, it's also simple:
 > 
 >       bzr rebase ../parent

No, it's not that simple.  You need to specify three things which can
vary more or less independently: the first version to rebase, the last
version to rebase, and where to rebase them.  The bzr syntax only
allows two of the three: the current branch, and the point at which to
rebase.  It *can't* work in the general case.

 > (modulo bugs in `rebase').  Or, if we don't want to futz with
 > `rebase':
 > 
 >       bzr merge -rN1..N2 ../feature-branch
 > 
 > assuming that revisions N1 to N2 introduced "the feature" on the
 > other branch.

That does the wrong thing.  Although it merges the right content, it
loses all the history.

 > > *Explaining how* to do it, though, requires some knowledge.

 > I have no problems explaining why the latter works, see below.  As
 > for the former, the documentation of `rebase' seem to be clear
 > enough, FWIW.

Then you have *real* problems, because you think you know what you're
doing, but you don't.

Of course, it's possible that your model is sufficient for your
purposes.  Maybe you don't use rebase at all, or maybe history loss
doesn't bother you in this case.  Good for you!  But that makes your
input into discussions of *project* workflow quite suspect, because
your advice is at best irrelevant, and at worst wrong, for what some
of your colleagues want to do.

 > > 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?

 > I don't see it as a limitation.  Disk space is not at premium
 > anymore.  OTOH, the mental resources needed to remember which
 > branch I'm on now _are_ at premium with this old fart.  I prefer to
 > see the branch name right there at the shell prompt, to serve as a
 > reminder.

Good for you.  But why should your preferences rules *my* workflow?

It's not a question of disk space.  It's a question of preferred
workflow.  I like git's colocated model for some purposes, like a
quick switch to a branch for accumulating typo fixes, or recording
alternative specifications of a feature and their implementations.  I
also like it because it allows me to group some branches that are
related together, and add or delete branches as they become
(ir)relevant to that task, then clone the whole thing to a difference
host, or offer it to a colleague.

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

 > "bzr merge -rN1..N2 FOO" applies to the current branch the changes
 > introduced in revisions (N1..N2] of branch FOO.

Yes, it does that ... for the content.  However, it forgets the
history N1..N2 which was just applied, which is undesirable for two
reasons: first, I want to see it with an ordinary log command (not
switching branches), and second, at least in theory the VCS should be
able to use that information to avoid merge conflicts in the future
should that branch be merged again.

 > That's the simple mental model I have about "bzr merge", and it
 > seems to work for me.  For the situation you describe, it should
 > add files `baz' and `quux', which were added in revisions 3 and 4
 > in branch foo.
 > 
 > > Did you predict the output correctly?
 > 
 > Yes, assuming you mean this output:
 > 
 >   /tmp/test/bar$ bzr merge -r2..4 ../foo; bzr commit -m merge
 >   +N  baz
 >   +N  quux
 >   All changes applied successfully.
 >   Committing to: /tmp/test/bar/
 >   added baz
 >   added quux
 >   Committed revision 2.

No, I mean the output of bzr log -n0.  In particular, were you
expecting that the history of changes you just merged would just
vanish into thin air?