Thread (5 messages) flat view 5 messages, 3 authors, 2016-06-15

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

From: Jeff King <hidden>
Date: 2016-06-15 22:54:49

On Wed, Sep 19, 2012 at 01:31:50PM -0700, Kevin Ballard wrote:
quoted
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).
Sure, that would probably make sense. Care to roll a patch with
suggested wording?

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help