Re: Rename detection at git log

[Andy Parkins <andyparkins@gmail.com>]

On Monday 2006 November 20 10:07, Junio C Hamano wrote:

> The real issue here is because the b/a on the command line
> applies on the input-side, and does not act as the output
> filter.  This comes from _very_ early design decision and if you
> dig the list archive you will see Linus and I arguing about
> diffcore-pathspec (which later died off).

I don't think so; even without the b/a on the command line, git does not find 
copies made in this way...

$ git init-db
defaulting to local storage area
$ date > fileA
$ git add fileA
$ git commit -a -m "fileA"
Committing initial tree 3ef607fd139dd955f868305462d99dfc4cfff70f
$ cp fileA fileB
$ git add fileB
$ git commit -a -m "fileA -> fileB"

Now let's try and get git-diff to notice this was a copy...

$ git diff HEAD^..HEAD | cat
diff --git a/fileB b/fileB
new file mode 100644
index 0000000..ec620df
--- /dev/null
+++ b/fileB
@@ -0,0 +1 @@
+Mon Nov 20 10:16:29 GMT 2006
$ git diff -C HEAD^..HEAD | cat
diff --git a/fileB b/fileB
new file mode 100644
index 0000000..ec620df
--- /dev/null
+++ b/fileB
@@ -0,0 +1 @@
+Mon Nov 20 10:16:29 GMT 2006
$ git diff --find-copies-harder HEAD^..HEAD | cat
diff --git a/fileA b/fileB
similarity index 100%
copy from fileA
copy to fileB

As I said - I don't see what "-C" ever does for you in all but the rarest of 
uses.  --find-copies-harder is the only way to list copies successfully.  
It's nothing to do with any input or output filtering.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE