Jeff King <peff@xxxxxxxx> 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" family. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html