On Thu, Oct 19, 2006 at 01:46:39PM +0200 I heard the voice of
Petr Baudis, and lo! it spake thus:
>
> Does Bazaar support those? (I can't really say it's a defect if it
> doesn't...)
By default, merge will refuse to do its thing if there are uncommitted
changes in the working tree, whether those changes are something
you've done, or the pending results of a previous merge. A '--force'
arg to merge will make it go forward though, so yes, you can merge
multiple other branches in one merge if you want to.
Actually, I can kill 2 birds here. Quick little bictopus merge:
% bzr log --show-ids
------------------------------------------------------------
revno: 2
revision-id: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
committer: Matthew Fuller <fullermd@xxxxxxxxxxxxxxx>
branch nick: a
timestamp: Thu 2006-10-19 10:18:56 -0500
message:
merge
------------------------------------------------------------
revno: 1.2.1
merged: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
committer: Matthew Fuller <fullermd@xxxxxxxxxxxxxxx>
branch nick: b
timestamp: Thu 2006-10-19 10:18:00 -0500
message:
bar
------------------------------------------------------------
revno: 1.1.1
merged: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
committer: Matthew Fuller <fullermd@xxxxxxxxxxxxxxx>
committer: Matthew Fuller <fullermd@xxxxxxxxxxxxxxx>
branch nick: c
timestamp: Thu 2006-10-19 10:18:07 -0500
message:
baz
------------------------------------------------------------
revno: 1
revision-id: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
committer: Matthew Fuller <fullermd@xxxxxxxxxxxxxxx>
branch nick: a
timestamp: Thu 2006-10-19 10:14:37 -0500
message:
Foo
(I'll refer to revids by the last segment)
Note that this also shows the "left-most" parent distinction. The
"left-most" parent of revno 2 (c3b406b8bcdfb537) is revno 1
(5b99dff6ed1d76cd), because that's the last thing I did in THIS
branch. That's my 'mainline'; the commits from branch b
(2fe41e4949f5e237) and c (3d7047e387edcad9) are then additional
parents of the merge at revno 2.
The graph for branch a now looks something like (calling the 3
original commits 'a', 'b', and 'c' and the merge rev 'D'):
a-.
|\ \
| b c
|/ /
D-'
The 2fe41e4949f5e237 rev is on branch b's mainline forever, and it has
a single-digit revno (2 in this case) on branch b, but it's not on
mine in a. Now, let's pretend we're branch b, and we want to pick up
from a. Because a is a superset of b, we could pull ('fast-forward')
a. If we do that, the graph in b will be identical to a (and so 'log'
will be too). That, AIUI, is what you'd do in git.
In the bzr methodology we've been discussing, where you want to
maintain your branch's identity, you'd instead merge from a into b.
You've got two new revisions to pick up in doing so; the
3d7047e387edcad9 from branch c, and the merge rev c3b406b8bcdfb537;
you already have 2fe41e4949f5e237 on your mainline. So, post-merge,
the log for b will look like (somewhat trimmed for space):
------------------------------------------------------------
revno: 3
revision-id: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
branch nick: b
------------------------------------------------------------
revno: 1.1.1
merged: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
branch nick: a
------------------------------------------------------------
revno: 1.2.1
merged: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
branch nick: c
------------------------------------------------------------
revno: 2
revision-id: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
parent: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
branch nick: b
------------------------------------------------------------
revno: 1
revision-id: fullermd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
branch nick: a
The 2fe41e4949f5e237 which was originally on b's mainline is still on
the mainline at revno 2. The graph in b now looks like (adding the
new 'E' merge commit)[0]:
a-.
|\ \
b c |
|\|/
| D
|/
E
Now, the question of "is that merge commit E really necessary, when
you could just attach D to the end of the graph and create something
like:
a-.
|\ \
b c |
|/ /
D-'
is perhaps a useful question (and one that there's obviously
disagreement on). And it may be a fruitful one to discuss, if we're
not way off in the weeds already. But, it's also not QUITE the same
question as "Is the left-vs-other path distinction meaningful and to
be preserved?"
[0] For reference at this point:
a: 5b99dff6ed1d76cd
b: 2fe41e4949f5e237
c: 3d7047e387edcad9
D: c3b406b8bcdfb537
E: 78d6209cd0f5f2f7
--
Matthew Fuller (MF4839) | fullermd@xxxxxxxxxxxxxxx
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html