Re: How to fork a file (git cp ?)

[Jeff King <peff@peff.net>]

On Thu, May 05, 2011 at 10:01:32PM +0200, Piotr Krukowiecki wrote:

> >> I think that is what exactly "blame -C -C" gives you.
> >
> > For that to be useful, one has to suspect, the file was derived by copying
> > something else... Simple "git log" will not suggest that -- unless the
> > commit message, that adds the new copy of a file points to it...
> 
> Maybe it should be the default (performance issues?)

Performance is part of it, but also the fact that "--follow" has some
limitations. For example, you can't use it with arbitrary pathspecs. I
hope to fix that at some point. There was a GSoC proposal, but it didn't
get selected; I'm hoping to work on it myself sometime this summer.

> BTW, I don't understand why 'status' shows renames but not copies:
> 
> $ cp f fcp && git add fcp && git status
> # Changes to be committed:
> #	new file:   fcp
> 
> $ mv f fmv && git add fmv && git rm f && git status
> # Changes to be committed:
> #	renamed:    f -> fmv
> 
> I would expect sth like "copied: f -> fcp".

Yeah, we probably should do copy detection. Even weirder, we seem to do
rename detection for what's to be committed, but not for what's in the
worktree.

If you want to do a patch, the changes would go in wt-status.c, in the
functions:

  wt_status_collect_changes_worktree
  wt_status_collect_changes_index

> It should not be a problem performance-wise...

For people running "git status" manually, no. But something like
FIND_COPIES_HARDER may be expensive on a big tree for people who use
"git status" output as part of their shell prompt. So probably it should
be configurable.

-Peff