Re: Proper tracking of copies in git log and others

[Avery Pennarun <apenwarr@gmail.com>]

On Tue, Jul 7, 2009 at 9:48 AM, Michael J
Gruber<git@drmicha.warpmail.net> 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