Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 21 Jun 2007, Linus Torvalds wrote: > > > > 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. - 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
