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

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:54:49

Jeff King [off-list ref] writes:
quoted hunk
On Tue, Sep 18, 2012 at 09:38:32PM -0700, Junio C Hamano wrote:
quoted
That is a totally wrong message to send.  You failed to teach the
reader that there is no need to do anything special to tell the
command to follow per-line origin across renames.

So if anything, I would phrase it this way instead:

    --follow::
          This option is accepted but silently ignored.  "git blame"
	  follows per-line origin across renames without any special
	  options, and there is no reason to use this option.
I think that is much better than Drew's text. But I really wonder if the
right solution is to simply disallow --follow. It does not do anything,
and it is not documented. There is no special reason to think that it
would do anything, except by people who try it. So perhaps that is the
right time to say "no, this is not a valid option".

Like this (totally untested) patch:
diff --git a/builtin/blame.c b/builtin/blame.c
index 0e102bf..412d6dd 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2365,6 +2365,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
 			ctx.argv[0] = "--children";
 			reverse = 1;
 		}
+		else if (!strcmp(ctx.argv[0], "--follow")) {
+			error("unknown option `--follow`");
+			usage_with_options(blame_opt_usage, options);
+		}
 		parse_revision_opt(&revs, &ctx, options, blame_opt_usage);
 	}
 parse_done:
This patch would not hurt existing users very much; blame is an
unlikely thing to run in scripts, and it is easy to remove the
misguided --follow from them.

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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help