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

[John Arbash Meinel]

Aaron Bentley wrote:
> 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.

It will show up, but it will return C, not D. Because it looks at the
revision="C" property, not at the current revision.

> 
>> 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

Well, B and C were merged to create D. We have been distinguishing them
as mainline parent, and merge parent. I was just commenting on the
asymmetry. (It certainly can be something we are okay with, but it
should be noted).

John
=:->