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

From: Jeff King <peff@peff.net>
Date: May 5, 2011, 20:07 UTC
Message-ID: <20110505200715.GC1770@sigill.intra.peff.net>
In-Reply-To: <BANLkTikE8aMh6RUDzrh=SuOxvKxuPShQhQ@mail.gmail.com>

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

Show 7 quoted lines

> >> 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.

Show 11 quoted lines

> 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