Re: [PATCH] Documentation/git-blame.txt: --follow is a NO-OP

From: Kevin Ballard <kevin@sb.org>
Date: Sep 19, 2012, 20:31 UTC
Message-ID: <C07F05AC-8FBF-4F09-AF13-A291181A06D9@sb.org>
In-Reply-To: <20120919194213.GB21950@sigill.intra.peff.net>

On Sep 19, 2012, at 12:42 PM, Jeff King <peff@peff.net> wrote:

Show 19 quoted lines

>> 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