[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
`rebase':
bzr merge -rN1..N2 ../feature-branch
assuming that revisions N1 to N2 introduced "the feature" on the other
branch.
> *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.
> > 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.
- Re: base, (continued)
- Re: base, Stephen J. Turnbull, 2010/08/26
- Re: base, Eli Zaretskii, 2010/08/26
- Re: base, Stephen J. Turnbull, 2010/08/27
- Re: base, Eli Zaretskii, 2010/08/27
- Re: base, Miles Bader, 2010/08/27
- Re: base, Eli Zaretskii, 2010/08/27
- Re: base, Stephen J. Turnbull, 2010/08/28
- Re: base,
Eli Zaretskii <=
- Re: base, Leo, 2010/08/28
- Re: base, Eli Zaretskii, 2010/08/28
- Re: base, Leo, 2010/08/28
- Re: base, Stephen J. Turnbull, 2010/08/28
- Re: base, Eli Zaretskii, 2010/08/28
- Re: base, Stephen J. Turnbull, 2010/08/29
- Re: base, Uday S Reddy, 2010/08/26
- Re: base, Stephen J. Turnbull, 2010/08/25
- Re: base, Eli Zaretskii, 2010/08/25
- Re: base, Stephen J. Turnbull, 2010/08/26