Re: possible 'git cp'/how does git detect copies

Mircea Bardac <dev@xxxxxxxxxx> · Fri, 27 Jun 2008 14:16:41 +0100

Hi,

Santi Béjar wrote:

On Fri, Jun 27, 2008 at 14:40, Mircea Bardac <dev@xxxxxxxxxxxxxxxxx> wrote:

I was looking today at duplicating a file but, I soon realized that there is
no 'git cp' command (this was the "deductive approach to git commands",
starting from git mv/rm/...). How does "git diff -C" detect copies (-C is
used for this, according to the documentation)?

Did you followed the "See also −−find−copies−harder."?

I knew this from before but for some reason I forgot about it when I 

tried it now. The documentation for "git diff -C" is a bit misleading. I 

have originally tested on git 1.5.2.something and the documentation for 

-C didn't point to --find-copies-harder. I've quickly installed 1.5.6.1 

to test the behavior but not the man pages.

Looking over the online docs for 1.5.6.1, it appears that there is now a 

reference to --find-copies-harder.

Even so, saying just that "Detect copies as well as renames." is not 

enough, as it assumes that there is no restriction on the detection process.

From --find-copies-harder

"For performance reasons, by default, -C option finds copies only if the 

original file of the copy was modified in the same changeset." should be 

moved to -C.

On a very simple test, I couldn't see this working. I just copied one file,
added it, committed the change, ran "git diff -C HEAD^!". There is no place
saying that it's contents is copied from some other file (both files are in
the repository now).

"git blame -C new_copied_file" also doesn't show the commits for the
original file.

git blame -C -C new_copied_file

Ah, duplicating the parameter. Looking better over these options I have 

noticed that --find-copies-harder for "git diff" can also be replaced 

with an extra -C. A little bit of consistency would help: either

"-C -C", either "--find-copies-harder" in both git blame/diff. Removing 

from the documentation the deprecated version but keeping the 

implementation for backwards compatibility might be a solution.

Many thanks,
Mircea

P.S. I know that patches are encouraged and technically it's pretty 

simple to create a documentation patch, but I have not yet formed myself 

a workflow for sending patches via Git to a maillist (this is a pending 

task for me)

--
http://mircea.bardac.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html