Re* [PATCH] Documentation/git-blame.txt: --follow is a NO-OP
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 21, 2012, 19:09 UTC
- Message-ID
- <7v7grn5h1l.fsf_-_@alter.siamese.dyndns.org>
- In-Reply-To
- <20120919203738.GA24383@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 18 quoted lines
> On Wed, Sep 19, 2012 at 01:31:50PM -0700, Kevin Ballard wrote: > >> > 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?
Let's do this for now instead. That would make it clear to people who (rightly or wrongly) think the "--follow" option should do something that we already do so, and explain the output that they see when they do give the "--follow" option to the command.
I may do a "--no-follow" patch as a follow-up, or I may not, depending on the mood and workload.
Documentation/git-blame.txt | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git c/Documentation/git-blame.txt w/Documentation/git-blame.txt index 7ee9236..809823e 100644 --- c/Documentation/git-blame.txt +++ w/Documentation/git-blame.txt @@ -20,6 +20,12 @@ last modified the line. Optionally, start annotating from the given revision. The command can also limit the range of lines annotated. +The origin of lines is automatically followed across whole-file +renames (currently there is no option to turn the rename-following +off). To follow lines moved from one file to another, or to follow +lines that were copied and pasted from another file, etc., see the +`-C` and `-M` options. + The report does not tell you anything about lines which have been deleted or replaced; you need to use a tool such as 'git diff' or the "pickaxe" interface briefly mentioned in the following paragraph.