SZEDER Gábor [off-list ref] writes:
A while ago in a related thread Peff remarked about 'git commit's
'--quiet' and '--verbose' options:
I think that is a UX mistake, and we would not do
it that way if designing from scratch. But we're stuck with it for
historical reasons (I'd probably name "--verbose" as "--show-diff" or
something if writing it today).
http://thread.gmane.org/gmane.comp.version-control.git/289027/focus=289069
Then I replied:
However, that doesn't mean that we have to spread this badly chosen
name from options to config variables, does it? I think that if we
are going to define a new config variable today, then it should be
named properly, and it's better not to call it 'commit.verbose', but
'commit.showDiff' or something.
http://thread.gmane.org/gmane.comp.version-control.git/289027/focus=289303
Any thoughts on this? Before a poorly named config variable enters to
the codebase and we'll have to maintain it "forever"...
My thoughts are --show-diff would probably be a UI mistake of a
different sort, if you are anticipating that the different kinds of
information to be shown in verbose modes would proliferate and that
you would want to give the user flexibility to pick and choose to
use some while not using some other among them. You would end up
having --show-xyzzy --show-frotz --show-nitfol ... options.
I am not convinced that we would want such a degree of flexibility
in the first place, but even if we did, we'd be better off giving
that as "--verbose=diff,xyzzy,frotz...", I would think.
And commit.verbose that begins its life as a simple boolean, which
can be extended to become bool-or-string if needed, is better than
having commit.showDiff, commit.showXyzzy, commit.showFrotz, etc.
On Fri, May 06, 2016 at 08:33:15AM -0700, Junio C Hamano wrote:
quoted
Then I replied:
However, that doesn't mean that we have to spread this badly chosen
name from options to config variables, does it? I think that if we
are going to define a new config variable today, then it should be
named properly, and it's better not to call it 'commit.verbose', but
'commit.showDiff' or something.
http://thread.gmane.org/gmane.comp.version-control.git/289027/focus=289303
Any thoughts on this? Before a poorly named config variable enters to
the codebase and we'll have to maintain it "forever"...
My thoughts are --show-diff would probably be a UI mistake of a
different sort, if you are anticipating that the different kinds of
information to be shown in verbose modes would proliferate and that
you would want to give the user flexibility to pick and choose to
use some while not using some other among them. You would end up
having --show-xyzzy --show-frotz --show-nitfol ... options.
I am not convinced that we would want such a degree of flexibility
in the first place, but even if we did, we'd be better off giving
that as "--verbose=diff,xyzzy,frotz...", I would think.
And commit.verbose that begins its life as a simple boolean, which
can be extended to become bool-or-string if needed, is better than
having commit.showDiff, commit.showXyzzy, commit.showFrotz, etc.
I don't think anyone is anticipating more "--show-" options. It is just
that "--verbose" is the opposite of "--quiet" in most other commands,
and pertains to chattiness on the terminal about what is going on.
Whereas in git-commit, is about sticking some data in the commit message
template. Naively I'd expect it to cause commit to spew more data to
stderr about what's being committed, ident info, etc.
If you are thinking that there could be something like "--show-ident" to
replace that, I do not mind that too much. But IMHO that does not
address the root problem that commit's "--verbose" is not very much like
the same option in other commands. And something like
"--verbose=diff,ident" just seems to make that worse by coupling options
that otherwise don't have anything to do with each other.
-Peff
On Sat, May 7, 2016 at 7:32 AM, Jeff King [off-list ref] wrote:
On Fri, May 06, 2016 at 08:33:15AM -0700, Junio C Hamano wrote:
quoted
quoted
Then I replied:
However, that doesn't mean that we have to spread this badly chosen
name from options to config variables, does it? I think that if we
are going to define a new config variable today, then it should be
named properly, and it's better not to call it 'commit.verbose', but
'commit.showDiff' or something.
http://thread.gmane.org/gmane.comp.version-control.git/289027/focus=289303
Any thoughts on this? Before a poorly named config variable enters to
the codebase and we'll have to maintain it "forever"...
My thoughts are --show-diff would probably be a UI mistake of a
different sort, if you are anticipating that the different kinds of
information to be shown in verbose modes would proliferate and that
you would want to give the user flexibility to pick and choose to
use some while not using some other among them. You would end up
having --show-xyzzy --show-frotz --show-nitfol ... options.
I am not convinced that we would want such a degree of flexibility
in the first place, but even if we did, we'd be better off giving
that as "--verbose=diff,xyzzy,frotz...", I would think.
And commit.verbose that begins its life as a simple boolean, which
can be extended to become bool-or-string if needed, is better than
having commit.showDiff, commit.showXyzzy, commit.showFrotz, etc.
I don't think anyone is anticipating more "--show-" options. It is just
that "--verbose" is the opposite of "--quiet" in most other commands,
and pertains to chattiness on the terminal about what is going on.
Whereas in git-commit, is about sticking some data in the commit message
template. Naively I'd expect it to cause commit to spew more data to
stderr about what's being committed, ident info, etc.
If you are thinking that there could be something like "--show-ident" to
replace that, I do not mind that too much. But IMHO that does not
address the root problem that commit's "--verbose" is not very much like
the same option in other commands. And something like
"--verbose=diff,ident" just seems to make that worse by coupling options
that otherwise don't have anything to do with each other.
I can see how it looks out of place looked at like that, but for me as
a long-time user (aren't we all?) it never felt out of place because
it's a more verbose version of the output that's brought up when I'm
modifying it.
I.e. I'm modifying the commit message, so the message is brought up,
optionally and more verbosely I can ask for the whole commit
(including diff) to amend the commit message.
I.e. I really expect --verbose to be a more verbose version of the
primary thing a command is doing, which in the case of "commit
--amend" is giving me info I need to modify the commit.
It also fits nicely with "status --verbose" showing a diff of staged
changes, similar to how --verbose for commit shows the diff for a
commit being amended.