Re: [PATCH RFC 0/5] Introduce git-blame-tree(1) command

[Junio C Hamano <gitster@pobox.com>]

Marc Branchaud <marcnarc@xiplink.com> writes:

> My concern is about having two commands to do blaming (or "crediting"
> or whatever anyone wants to call it), instead of just one.

Existing "git blame" (or "git annotate") is about tracing the origin
of individual lines, so perhaps we can say "git blame" has two
modes, blame lines or blame files, and run the code for this new
mode with "git blame --mode=file" (and add "git blame --mode=line"
that is on by default that runs the original "git blame" code
paths)?

> I mean, from a usability point of view, it makes much more sense if
> "git blame" simply understood how to handle blaming a directory
> differently from blaming a file/blob:

I think this needs rephrasing: blaming a whole file (or a whole
tree) differently from blaming individual lines.

As lines can move across files, and we do find such moves while
tracing the origin of each line, "blaming a file" is not quite the
right way to think about it.  "blaming lines in a file", perhaps.

> Git should be smart enough to figure out what to do from just whether
> or not the last argument is a file or directory.

Ah, that is interesting.  We do not have to introduce "--mode=line/file"
option.  Just see if the given pathspec names a tree object in the starting
commit and trigger the blame-tree logic, otherwise we just line the
"blame lines in a file" mode.  So dispatching between the two modes
is almost trivial.  I like that.

After command line option parsing, however, there may need some
sanity checking logic like "You said you want to blame the t/
directory and its contents, but at the same time you have -L1,10
to say you only want to blame the first 10 lines, which is an option
that does not make sense in blame-tree mode, so I abort".  As long
as that is cleanly done, I think it is a good direction forward.