Re: Proper tracking of copies in git log and others

On Tue, Jul 7, 2009 at 9:48 AM, Michael J Gruber<git@drmicha.warpmail.net> wrote:

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