Andy Parkins [off-list ref] writes:
On Monday 2006 November 20 05:57, Alexander Litvinov wrote:
quoted
quoted
PAGER=cat git log -M -C --pretty=oneline b/a
I've come across this too. Personally I'm not sure what use "-C" is. From
the manpage, man git-diff-files (no, this isn't the place I'd look either).
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).
What it means is that "git log" will look at path that matches
b/a (that means b/a/c and b/a/d are looked at, if b/a were a
directory). Since path "a" which is what the file was
originally at is not something the pattern b/a matches, there is
no way b/a is noticed as a rename from a.
I've been meaning to resurrect Fredrik's --single-follow=path
patch but haven't had time to recently, with all the other
interesting discussion happening on the list.
Junio C Hamano wrote:
Andy Parkins [off-list ref] writes:
quoted
On Monday 2006 November 20 05:57, Alexander Litvinov wrote:
quoted
quoted
PAGER=cat git log -M -C --pretty=oneline b/a
I've come across this too. Personally I'm not sure what use "-C" is. From
the manpage, man git-diff-files (no, this isn't the place I'd look either).
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).
What it means is that "git log" will look at path that matches
b/a (that means b/a/c and b/a/d are looked at, if b/a were a
directory). Since path "a" which is what the file was
originally at is not something the pattern b/a matches, there is
no way b/a is noticed as a rename from a.
I've been meaning to resurrect Fredrik's --single-follow=path
patch but haven't had time to recently, with all the other
interesting discussion happening on the list.
But for now, you can use
PAGER= git log -M -C -- b/a a
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
What it means is that "git log" will look at path that matches
b/a (that means b/a/c and b/a/d are looked at, if b/a were a
directory). Since path "a" which is what the file was
originally at is not something the pattern b/a matches, there is
no way b/a is noticed as a rename from a.
I have found that git blame show correct commits for this case. But I am still
in trouble then examining file's history. I have found I can use
git show -C -M commit-sha1
for commit there file was created to see if this was a rename :-)
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