Looking for a way to get merge directive contents

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
| John Arbash Meinel wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|
|> Erik Bågfors wrote:
|> | When I run merge or pull, the directive acts like a branch "bzr pull
|> | <directive>".
|> |
|> | Why shouldn't I be able to run "bzr log <directive>"?
|
|> A directive only has meaning in the context of a branch.
|
| A directive also indicates which branch it's supposed to be merged into,
| so it can always use that branch.
|

Provided it is public and available (you are online, etc.)

|> 'log' is
|> defined in
|> terms of a single branch, while 'pull' and 'merge' have 2 branches.
|
| Well, they have an input, which may be a merge directive or a branch,
| and they have an output branch.

It is still another branch for context. You're right that I said 2 branches when
it may be 1 branch and a merge directive. I was mostly saying that they have 2
objects, while 'bzr log' only has 1.

In fact, 'bzr log http://foobar' could be sped up a lot if we used the local
branch as context (if available). So we might consider doing it anyway.

|
|  So
|> you have
|> context to understand the merge directive. (Mostly because a lot of the
|> entries
|> will be deltas against existing revisions, so we can't recreate the full
|> text
|> otherwise.)
|
| However, revision entries in particular are always stored as fulltexts.

Sure, until someone wants to do 'bzr log --verbose', etc.

John
=:->

|
|> That said, I believe Robert's work on stacked branches might make it a bit
|> easier to pretend a merge directive is just another branch with limited
|> history.
|
| Indeed.
|
| Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhFfckACgkQJdeBCYSNAAMBqQCgp4VTSI8ruMJPYLyhpzOOpuyE
rtgAoNhDen/UVkchCHfp8n3NYBbjtBG+
=dPMR
-----END PGP SIGNATURE-----