Jeff King <p...@peff.net> writes:
> I guess it depends on your perspective. I can see the argument that
> blame is already doing what --follow would ask for, and thus it is a
> no-op. I think of it more as --follow is nonsensical for blame.
Is "--follow" a nonsense in the context of blame? I am not so sure.
I think it all boils down to this question:
Does "blame" that does not follow rename make sense?
When you think about -M (allows us to keep track of the origin of
lines inside a single file when they are moved around) and -C
(allows us to keep track of the origin of lines that migrate from
another file), "follow across whole-file rename" is another optional
mode of operation in the same class to tell the command to pay more
processing cost to buy better precision. When you know what you are
interested in happened entirely inside a file that was never
renamed, "blame -M" without "-C" and without whole-file rename
tracking is a sensible way to set that trade-off, even though we
currently do not have a way to say "--no-follow".
Eventually we would review and accept a patch to fix "--follow" by
somebody and that patch will make "--follow" truly follows renames
by keeping track of a single pathspec used to limit the changes per
ancestry traversal path, instead of switching one global one, which
is the current hack does.
Once that happens, what "--follow" does will match exactly what the
current "blame" internally (and unconditionally) does. The current
"blame" pays no attention to "--follow" because it wants to do the
right thing without letting the broken "--follow" logic to take over
and do a half-hearted job at following renames.
So if we were to do something special for "--follow" inside blame, I
think the right thing to do is probably to silently ignore, and in
addition, accept "--no-follow" and disable the whole-file rename
tracking logic. When a true "--follow" comes along, we may be able
to rip out the whole-file rename tracking logic from "blame" and let
the version of "--follow" implemented correctly for the "log"
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html