possible 'git cp'/how does git detect copies

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)?

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.

This is all with 1.5.6.1.

I am probably missing something here... but I can't produce an example of copied contents that actually works. Any hint would be appreciated.

I found this older thread [1] on "git cp" but the discussion appears to have stalled at some point. If there is indeed no use of a "git cp" command, I would like at least some info on how content copies are being detected, since I haven't seen this working.

[1] http://kerneltrap.org/mailarchive/git/2008/2/3/705424

Many thanks, Mircea

-- http://mircea.bardac.net

On Fri, Jun 27, 2008 at 14:40, Mircea Bardac <dev@mircea.bardac.net> wrote:

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

--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.  This flag makes the command
        inspect unmodified files as candidates for the source of
        copy.  This is a very expensive operation for large
        projects, so use it with caution.  Giving more than one
        `-C` option has the same effect.

git blame -C -C new_copied_file

Hi,

Santi Béjar wrote:

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.

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

On Fri, Jun 27, 2008 at 12:40:22PM +0000, Mircea Bardac wrote:

  By comparing if files (blobs) are alike. It has some heuristics to
guess which files have good changes to be copies or renames of each
others. But it recomputes the information each time.

  You probably want to use -C -C -M actually.

  If you really need it, you can and an alias alias.cp=!cp and be done
with it ;P

On Fri, Jun 27, 2008 at 03:00:06PM +0200, Pierre Habouzit <madcoder@debian.org> wrote:

Actually that's not that easy. git-mv moves untracked files and adds tracked files to the index as well. So such a git-cp would have to copy tracked and untracked files, and add tracked files to the index.

I did it in the past:

http://thread.gmane.org/gmane.comp.version-control.git/72388/focus=73347

but then we agreed about it's better not encouraging copy-and-paste.

Mircea Bardac schrieb:

If you modify the original file in the same commit, then you should see the copy. Otherwise, you can try git diff -C -C aka --find-copies-harder.

-- Hannes