What is a modification?

[Martin von Gagern]

On 07.10.2011 09:13, John Arbash Meinel wrote:
> I'm a little concerned if 'bzr log FOO' sometimes outputs revision X
> and sometimes doesn't, depending on which branch you run it in.

It's what I'd expect intuitively. And I guess it is also what makes bzr
different from git and friends: bzr has the clear concept of a main line
of development, affecting revision numbers, log indentation, and so on.
This kind of branch dependency therefore feels right to me. I do
understand, however, that this might not be true for everybody.

> One option is to get rid of showing INHERITED revisions.

Good point. I can imagine use cases for both approaches, logs consisting
only of ORIGINAL modifications, and logs including a route of INHERITED
ones. So I believe I'd like to have a command line option to choose
among these.

One big argument for ORIGINAL modifications only is that it should be
much easier to implement, and probably show better performance as well,
as there would be no need to identify the corresponding merge path.

I also beliebe that there might be some aspects about that approach
which might themselves lead to confusion. For one, it would mean that
indentation of logs would suffer somewhat, as you'd have deeply indented
ORIGINAL revisions without the less depply indented merges above them.
The --omit-merges option I added for log can cause the same kind of
"floating" log entries, and I know vila didn't like that aspect about
them. I believe that behaviour is all right if an option specifically
requests it, but I'm not that happy with making it the default for
filtered logs. Disabling indentation would be an alternative, not sure
how I feel about that.

A second possible source of confusion is the following: what to do for a
log with the root of the tree given as command line argument. Omitting
purely INHERITED revisions from its output would seem logical if you do
so for other subdirectories, but that would mean that "bzr log -n0 ."
would potentially output less stuff than "bzr log -n0". As a
consequence, we'd need a -d option for bzr log as well, so that we could
get the complete log of some given directory without filtering. Now that
I think of it, branches split from a larger code tree are already
affected by this issue. I just filed
https://bugs.launchpad.net/bzr/+bug/869912 about this.

Not including INHERITED modifications might also give users an incorrect
idea as to when a feature became available in mainline, or of the people
involved in bringing it there. So there are cases where you'd want those
INHERITED revisions for their metadata.

> Maybe if we had better ways of annotating the output, to indicate
> whether a given change was inherited vs original?

One possibility, yes. I like this. Could be part of the [merge]
annotation we already have, as only merges will be able to inherit.

Greetings,
 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20111007/8569eb28/attachment.pgp>