On Sep 19, 2012, at 12:42 PM, Jeff King <peff@xxxxxxxx> wrote: >> So I am in general OK with it, but if we are to go that route, we >> should make sure that the documentation makes it clear that blame >> follows whole-file renames without any special instruction before >> doing so. Otherwise, it again will send the same wrong message to >> people who try to use the "--follow" from their experience with >> "log", no? > > 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. But I > do not think either is wrong per se, and there is no reason not to help > people who come to git thinking the former. So yes, I think > documentation in either case is probably a good thing. > > I am a little lukewarm on my patch if only because of the precedent it > sets. There are a trillion options that revision.c parses that are not > necessarily meaningful or implemented for sub-commands that piggy-back > on its option parser. I'm not sure we want to get into manually > detecting and disallowing each one in every caller. I tend to agree with your final sentiment there. But the point that users may not realize that blame already follows is also valid. Perhaps we should catch --follow, as in your patch, but instead of saying that it's an unknown argument, just print out a helpful message saying blame already follows renames (and then continue with the blame anyway, so as to not set a precedent to abort on unknown-but-currently-accepted flags). -Kevin -- 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