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

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.

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.

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?

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

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