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