Marc Branchaud <marcnarc@xxxxxxxxxxx> 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.
