From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:17
Junio C Hamano [off-list ref] wrote:
The blame window shows "who wrote the piece originally" and "who
moved it there" in two columns. In order to identify the former
more correctly, it helps to use the new -w option.
I've wanted to do this since you introduced `git blame -w`. But I
can't use it, because I cannot trust that -w is there. For example
it is not in maint, but the new blame viewer from git-gui is.
Apply my --list-features patch to core Git and I'll activate -w in
git-gui when --list-features claims the 'blame-ignore-whitespace'
feature is available.
;-)
--
Shawn.
I've wanted to do this since you introduced `git blame -w`. But I
can't use it, because I cannot trust that -w is there. For example
it is not in maint, but the new blame viewer from git-gui is.
Actually, I think there's a different fundamental problem, namely that
git-gui doesn't seem to accept parameters.
I'd personally rather *not* have git-gui make the -w/-M/-C choice for me.
Why don't you just allow the user to say? Sometimes I might want to see
who introduced broken whitespace. Let me say
git gui blame -w filename.c
please? Instead of making that choice for me, and then blaming git for
something that wasn't git's problem.
Linus
I'd personally rather *not* have git-gui make the -w/-M/-C choice for me.
Why don't you just allow the user to say? Sometimes I might want to see
who introduced broken whitespace. Let me say
git gui blame -w filename.c
please? Instead of making that choice for me, and then blaming git for
something that wasn't git's problem.
Side note - this ended up being one reason why "gitk" is so good. It just
passed down the arguments to "git-rev-list", and it allowed me to improve
on the original gitk without gitk ever even _realizing_ it was improved
upon. All the pathname filtering etc was done without gitk ever learning
about it - it "just worked".
Linus
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:17
Linus Torvalds [off-list ref] wrote:
On Thu, 21 Jun 2007, Linus Torvalds wrote:
quoted
I'd personally rather *not* have git-gui make the -w/-M/-C choice for me.
Why don't you just allow the user to say? Sometimes I might want to see
who introduced broken whitespace. Let me say
git gui blame -w filename.c
please? Instead of making that choice for me, and then blaming git for
something that wasn't git's problem.
Side note - this ended up being one reason why "gitk" is so good. It just
passed down the arguments to "git-rev-list", and it allowed me to improve
on the original gitk without gitk ever even _realizing_ it was improved
upon. All the pathname filtering etc was done without gitk ever learning
about it - it "just worked".
Hmm. Good point about gitk. We all know you would rather not hack
Tcl to enhance tools, because you would prefer to work directly in C.
A lot of the stuff rev-list does in pure C does translate
directly into gitk, and its one of the features that I also love
most about gitk. Except --reverse; gitk doesn't really like to do
`gitk --reverse --all`. But it can be extremely amusing to run if
you are bored and have time to waste.
However. The new blame viewer supports two columns, and runs two
blame passes to obtain the information for them. I like that,
because it offers up a lot of information in a single compact view.
Which column do I send the option(s) to? Do I let the user specify
which column to apply the options onto?
git gui blame --left='-C -C' --right= filename.c ;# default
git gui blame --left=-w --right=-M filename.c ;# not default
? Or do I only show one column if the user supplies command line
options? Doesn't that limit the tool?
--
Shawn.