On Monday 2006 November 20 11:28, Junio C Hamano wrote: > If people are well disciplined, code refactoring (which can > trigger rename/copy detection) tend to affect both source and > destination files at the same time, so many times -C finds what > you want without --find-copies-harder. That's true; however, I don't think that refactoring is the common operation. Usually it's (as Jakub says) copy-and-modify-the-copy. In that case the original is untouched. > Having said all that, I think the rename/copy as a wholesale > operation on one file is an uninteresting special case. The > generic case that happens far more often in practice is the > lines moving around across files, and the new "git blame" gives > you better picture to answer "where the heck did this come from" > question. To help the version control system underneath, I have always obeyed the discipline of not to copy/move and modify in the same commit. git has the potential to remove this necessity, but I'd still like all my old commits to have the copies detected correctly. As an example: I've got a colleague who works on a project where each new version begins as a copy of the old one (it's not the way I'd work, but I think git is flexible enough to cope with anything). So, project1/ exists and is copied to project2/ to begin work. I suppose this is effectively branching using the filesystem rather than the version control system. I noticed (and was surprised) that git didn't detect this as a copy. No files were changed in the copy, so I thought git would easily spot this. The problem is that the next project can be a copy of either project1/ or project2/. All this has already gone on for a few years. I've recently imported this into git and was examining the history. I wanted to know for a particular subdirectory (of many) which of the others it was based off. I was in qgit, and found that the commit didn't show as a copy, it showed as a create, and hence I couldn't tell which was the parent project. It's a shame because all the mechanisms are there to show the operation, it just isn't shown (without --find-copies-harder). git-blame is obviously of huge use for these detailed analyses of individual line history. However, in the simple case of a commit being a 100% copy of another file, git lets me down. In fact, in the case described above, it wouldn't necessarily help me. What if it went like this: project1/ copied to project2/ project2/ copied to project3/ git-blame on a file in project3/ will show that its contents came from a project1 commit, whereas I want to know it's direct parent. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@xxxxxxxxx - 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