Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:17

"Shawn O. Pearce" [off-list ref] 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:
quoted hunk
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>

Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame

From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:43:17

Junio C Hamano [off-list ref] wrote:
Hmm.  Now, how does "git-blame" tell if there is usable git-gui
installed with it?  Will we have "git-gui --list-features"?
It can run `git gui version` and check to see that it is >= 0.7.3.
 
;-)


I'm actually not sure we want to apply this patch, hence the RFC
prefix I put on it.  Jakub suggested it, this crude implementation
was easy enough to hack together, so I posted a patch for someone
to play with if they were so inclined.

Maybe we should just put a link in the git-blame manual page to
the git-gui manual page:
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 66f1203..599e10b 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -36,6 +36,9 @@ $ git log --pretty=oneline -S'blame_usage'
 ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
 -----------------------------------------------------------------------------
 
+A powerful graphical viewer for the output of git-blame can be
+accessed through the blame subcommand of gitlink:git-gui[1].
+
 OPTIONS
 -------
 include::blame-options.txt[]
@@ -184,7 +187,8 @@ commit commentary), a blame viewer won't ever care.
 
 SEE ALSO
 --------
-gitlink:git-annotate[1]
+gitlink:git-annotate[1],
+gitlink:git-gui[1]
 
 AUTHOR
 ------
-- 
Shawn.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help