bzr log <file> displays irrelevant log records

Bug #51980 reported by Francis J. Lacoste on 2006-07-05
14
Affects Status Importance Assigned to Milestone
Bazaar
Medium
John A Meinel

Bug Description

When another branch was merged in the tree,
bzr log <file> will display the merged log records for any <file> even if the merge didn't involved the file. Ideally, only the log records relevant for <file> should be displayed from the merged log info.

Another problem is that bzr log <non-existent-file> displays the whole log history instead of simply saying 'File <non-existent-file> doesn't have any revision history'.

Consider raising the priority of this bug, since it removes the usefulness of bzr log when working in large projects which uses merging a lot (Launchpad for example).

Tags: ui Edit Tag help

This bzr session shows that once a merge was done, bzr log <FILE> will show the log entry of the merge even if the merge didn't implicate the requested file.

Changed in bzr:
assignee: nobody → larstiq
Francis J. Lacoste (flacoste) wrote :

This bug was added first as comments on bug 4663 (https://launchpad.net/products/bzr/+bug/4663). Disregard these comments in that context.

John A Meinel (jameinel) wrote :

Well, in those circumstances, the merge should be shown, because it does change the file contents.

But I would agree that we shouldn't show all of the revisions that were merged by that change.

I don't believe Larstiq's current log updates modify this behavior, but it might.

Changed in bzr:
importance: Untriaged → Medium
status: Unconfirmed → Confirmed
Martin Pool (mbp) wrote :

Let's try to fix this in 0.10; it's a significant UI bug.

John A Meinel (jameinel) wrote :

bumped to 0.11, and Wouter said he was to busy this month.

Changed in bzr:
assignee: larstiq → nobody
John A Meinel (jameinel) wrote :

related to bug 50793

Changed in bzr:
assignee: nobody → wang02139
Changed in bzr:
assignee: wang02139 → nobody
Kent Gibson (warthog618) on 2007-03-15
Changed in bzr:
assignee: nobody → warthog618
status: Confirmed → In Progress
John A Meinel (jameinel) wrote :

I guess I didn't realize that "bzr log <file>" displays all merges. But yes, this is indeed the same as bug 94499

The patch I'm uploading has a fix for this, which makes 'bzr log file' only show revisions which actually modified the file.

It also has an update to 'bzr log --verbose' so it shows the changes for merged revisions.

And it reduces the memory consumption for large 'bzr log' especially for 'bzr log --verbose' or 'bzr log filename'.

On Wed, 2007-03-21 at 20:57 +0000, John A Meinel wrote:
> I guess I didn't realize that "bzr log <file>" displays all merges. But
> yes, this is indeed the same as bug 94499
>
> The patch I'm uploading has a fix for this, which makes 'bzr log file'
> only show revisions which actually modified the file.
>
> It also has an update to 'bzr log --verbose' so it shows the changes for
> merged revisions.
>
> And it reduces the memory consumption for large 'bzr log' especially for
> 'bzr log --verbose' or 'bzr log filename'.

What definition of modified? (Does reparenting, exe change, name change
count?)

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

John A Meinel (jameinel) wrote :

At the moment, defined as being included in "tree.changes_from(tree.basis_tree())"

So I believe it does include all of those actions.

Kent Gibson (warthog618) on 2007-03-22
Changed in bzr:
assignee: warthog618 → jameinel
John A Meinel (jameinel) wrote :

Thanks to Kent Gibson for pushing this through. This is now fixed in 0.16rc1

Changed in bzr:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers