"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> To keep things really simple in git-blame we require that the new
> --gui option be the first argument on the command line, and cannot
> be combined with any other option. If it is the first argument
> then we punt our entire command line as-is into `git gui blame`,
> where that program's option parser will handle selecting out the
> revision and path, if present.
>
> Its simple and not very intrusive, but has the odd behavior that
> no option (like --contents) can be used along with it, because
> git-gui's own blame subcommand doesn't recognize them. On the
> other hand it is a useful DWIMery for `git gui blame`.
Hmm. Now, how does "git-blame" tell if there is usable git-gui
installed with it? Will we have "git-gui --list-features"?
In either case, I think this description is far less than optimum:
> diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
> index 66f1203..96ff02d 100644
> --- a/Documentation/git-blame.txt
> +++ b/Documentation/git-blame.txt
> @@ -10,6 +10,7 @@ SYNOPSIS
> [verse]
> 'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
> [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
> + [--gui]
> [<rev> | --contents <file>] [--] <file>
It essentially is two commands with different calling
conventions. I would probably do this instead if I were doing
this:
SYNOPSIS
--------
[verse]
'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
[-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
[<rev> | --contents <file>] [--] <file>
'git-blame' --gui [<rev>] [--] <file>
-
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
