[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: base

From: Eli Zaretskii
Subject: Re: base
Date: Sat, 28 Aug 2010 20:32:48 +0300

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden
> Date: Sun, 29 Aug 2010 01:25:45 +0900
> 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

In bzr, it's also simple:

      bzr rebase ../parent

(modulo bugs in `rebase').  Or, if we don't want to futz with

      bzr merge -rN1..N2 ../feature-branch

assuming that revisions N1 to N2 introduced "the feature" on the other

> *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,

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

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]