[MERGE][BUG] 51980: bzr log <file>returns inappropriate revisions

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> Personally, I'd like to see the merge commits in the long form, but
>> others may have different ideas.
> 
> So the difficulty with this is for things like:
> 
> A
> | \
> B C
> |/
> D
> 
> If 'C' modifies 'foo.py', but 'B' doesn't, then when we commit 'D', we
> have ie.revision = 'C'. Because 'D' doesn't change 'foo.py' relative to
> its parents.
> 
> So 'D' will not show up in either fileids_altered_by_revision_ids, nor
> in foo.py.kndx

I agree that it will not show up in foo.py.kndx.  But
fileids_altered_by_revision_ids looks at the delta between D and B, and
according to that delta, foo.py was altered.

It is necessary for it to work like that, because if C were a ghost,
fetch would fail to retrieve the necessary file revisions.

> However, all of this has a different problem, which is its asymmetry.
> 
> Specifically, Aaron has requested that
> 
> A
> |\
> B C
> |/
> D
> 
> Show C, D when C modifies 'foo'. (C did the modification, and D merged it).
> 
> However, what if 'B' modified foo. Arguably then we should show B, D,
> since D was a merge, and relative to C it modified foo.

What makes B a merge?  Are you considering all parents merges?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEUjy0F+nu1YWqI0RAlIIAJ4yE0eColYN73+5nTxyo/dwz3onzQCfcYgF
73QLuj2jngBDFdrwigYqf30=
=QSxo
-----END PGP SIGNATURE-----