On Tue, Jul 7, 2009 at 9:48 AM, Michael J Gruber<git@xxxxxxxxxxxxxxxxxxxx> wrote: > While there is a pending patch as Sean pointed out it still has issues. > For moves, "there is always only one", for copies there are at least > two. So which one do you follow? I think this is relatively easy, although the answer depends on whether you're merging or logging. Let's take the general case of n:m copies: n is the number of copies in the second commit, and m is the number in the base commit. So 1:1 is a move, and 2:1 is a copy, and (>2):1 is a multiple copy, and eg. 3:2 is an unclear case where you had more than one identical (or near-identical) file in the first place. A) Merges: if it's anything other than 1:1, it's totally non-obvious what to do, so I'll forgive git for doing pretty much anything. Bonus points for triggering a conflict so that I have to look at it. B) Logs: - if m > 1, choose the base file that's closest to the new one; its history should be pretty close to the right one, and arguably the new file could have come from there anyway. If there's more than one file of the same closeness, just pick one, because their histories are interchangeable anyway. - if n > 1, each file needs to have its base selected separately. It's totally okay for multiple files to have the same base. If files b, c, and d were all copied from a, I'd expect "git log --follow b c d" to show the copying operation, and then the history of a. Similarly for "git log --stat --follow b" for example. All of this seems to work (at least well enough for me) with the 1:1 move case, and also for copies if you use "git log --stat -C -C" (not restricting by filename). "git log --stat -C -C b" (restricting by filename) doesn't work for copies, and --follow doesn't help (the documentation for that options suggests it's only useful for moves). Unfortunately this also causes problems with following "effective move" operations: copy the file in one commit, and delete the original in the next. I've been known to make this mistake, and it breaks 'git log -C -C --follow filename', which is no fun. Thanks, Avery -- 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