diff output misleading when a file is deleted and becomes the target of a rename

Bug #268989 reported by Vincent Ladeuil
6
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
High
Unassigned
Breezy
Triaged
Low
Unassigned

Bug Description

As show be the attached script, diff output is misleading.

bzr rm foo
bzr mv bar foo
bzr diff

gives:

=== renamed file 'bar' => 'foo'
=== removed file 'foo'
--- foo 2008-09-11 13:14:15 +0000
+++ foo 1970-01-01 00:00:00 +0000
@@ -1,1 +0,0 @@
-foo content

which looks like 'foo' has been renamed and *then* deleted.

Tags: diff mysql
Revision history for this message
Vincent Ladeuil (vila) wrote :
Changed in bzr:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Vincent Ladeuil (vila) wrote :

While the example is simple this may seem innocuous but when it occurs multiple times during a merge it becomes really puzzling.

Using bzr status --show-ids helps to understand the issue but the diff output should be human-readable.

See also bug #40472.

Revision history for this message
John A Meinel (jameinel) wrote :

So there is a question as to what is the "right" fix

1) Always sort deletes before renames?
2) Check to see if a file is going to be put in the place, and ensure the sort order "on-the-fly" ?

The problem with the former, is that it will tend to group like "status" does, and give you:

=== deleted A
=== deleted B
....
=== renamed C => A

And the deleted section will be far away from the renamed section.

I *think* we sort by path, but I'm not sure how we handle ties. In this case, there are 2 paths at the same possible location, so we might be sorting by file_id.

Anyway, whatever fix, we should also check that switching:
bzr rm foo
bzr mv bar foo

for
bzr rm bar
bzr mv foo bar

has the same fix.

At present, doing that gives:
=== removed file 'bar'
--- bar 2008-09-11 21:35:10 +0000
+++ bar 1970-01-01 00:00:00 +0000
@@ -1,1 +0,0 @@
-bar

=== renamed file 'foo' => 'bar'

Which seems to be what you are asking for in the "bar => foo" case.

Revision history for this message
John A Meinel (jameinel) wrote :

I will also comment that whatever fix we do, we should probably also handle:

bzr rm foo
bzr commit -m "remove foo"
bzr add foo
bzr commit -m "add foo"
bzr diff -r -3..-1

which will show

=== deleted foo
=== added foo

or
=== added foo
=== deleted foo

Perhaps just adding a '--show-ids' to diff would be an easier way to resolve this?

Martin Pool (mbp)
Changed in bzr:
importance: Medium → High
Revision history for this message
Robert Collins (lifeless) wrote :

Perhaps we should show a diff between them and just note in the metadata that a id change has also occured?

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 268989] Re: diff output misleading when a file is deleted and becomes the target of a rename

2009/7/15 Robert Collins <email address hidden>:
> Perhaps we should show a diff between them and just note in the metadata
> that a id change has also occured?

I think that would be reasonable.

--
Martin <http://launchpad.net/~mbp/>

Martin Pool (mbp)
Changed in bzr:
status: Triaged → Confirmed
Jelmer Vernooij (jelmer)
tags: added: diff
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
tags: removed: check-for-breezy
Changed in brz:
importance: Undecided → Low
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.