From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:46
Jeff King [off-list ref] writes:
... That is, I don't want to have to remember "git grep
--full-tree" or "git grep /" every time
But that cuts both ways. If you change the default to full-tree,
people will forget to put "." every time when asking to limit to the
current directory.
If I am the one who sets the configuration variable to something more
sensible for my workflow, who am I hurting?
Somebody more clueful in git than you who is called to help you in your
repository when you have trouble. Obviously "you" in this sentence is not
Jeff King, but I think you get the point.
And re-read what I wrote in its entirety and notice I am not disagreeing
with you that the long term goal should be to have the default changed
consistently for all command to do the full tree. The important first
step is to make sure we are capable of doing both full tree and limit to
current directory and "grep" is one example that cannot do both, and be it
the --full-tree option or new /rooted-pathspec, we need some change _now_
that is backward compatible to pave the way for later changes. We give
people convenient way to choose between the two, and _train_ them to
express which way they want _without_ having to think. After that is
achieved, the default does not matter much and we can safely change the
default.
Think of it as a way to force existing users _unlearn_ the command
specific default we currently have. Because any change of default will
hurt them until that is done, we should start training them as early as
possible.
From: Jeff King <hidden> Date: 2016-06-15 22:47:46
On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
... That is, I don't want to have to remember "git grep
--full-tree" or "git grep /" every time
But that cuts both ways. If you change the default to full-tree,
people will forget to put "." every time when asking to limit to the
current directory.
I know. Which is why I am arguing for a configuration option.
Though as a side note, I think if you are going to err, it is probably
better to err in showing _too much_ data. It is easier for the user to
notice the situation and re-issue the command with more limits than it
is for them to notice that some results are missing and re-issue the
command with fewer limits.
quoted
If I am the one who sets the configuration variable to something more
sensible for my workflow, who am I hurting?
Somebody more clueful in git than you who is called to help you in your
repository when you have trouble. Obviously "you" in this sentence is not
Jeff King, but I think you get the point.
Clearly, because there _isn't_ anybody more clueful than me in git. ;)
But that is what my meta-rant elsewhere in the thread was about. Sure,
it hurts when more clueful people are called in (and that includes
asking for help on the list). But that evil to me is much less than a
user who is frustrated because they have to specify the same thing to
git over and over again.
And re-read what I wrote in its entirety and notice I am not disagreeing
with you that the long term goal should be to have the default changed
consistently for all command to do the full tree. The important first
step is to make sure we are capable of doing both full tree and limit to
current directory and "grep" is one example that cannot do both, and be it
the --full-tree option or new /rooted-pathspec, we need some change _now_
that is backward compatible to pave the way for later changes. We give
people convenient way to choose between the two, and _train_ them to
express which way they want _without_ having to think. After that is
achieved, the default does not matter much and we can safely change the
default.
Think of it as a way to force existing users _unlearn_ the command
specific default we currently have. Because any change of default will
hurt them until that is done, we should start training them as early as
possible.
I agree with all of this as far as changing the default goes. But the
point of my earlier messages was that I don't think there _is_ one sane
default. I really do want it different per-project. And that means a
configuration option.
-Peff
From: A Large Angry SCM <hidden> Date: 2016-06-15 22:47:46
Jeff King wrote:
On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
... That is, I don't want to have to remember "git grep
--full-tree" or "git grep /" every time
But that cuts both ways. If you change the default to full-tree,
people will forget to put "." every time when asking to limit to the
current directory.
I know. Which is why I am arguing for a configuration option.
Though as a side note, I think if you are going to err, it is probably
better to err in showing _too much_ data. It is easier for the user to
notice the situation and re-issue the command with more limits than it
is for them to notice that some results are missing and re-issue the
command with fewer limits.
quoted
quoted
If I am the one who sets the configuration variable to something more
sensible for my workflow, who am I hurting?
Somebody more clueful in git than you who is called to help you in your
repository when you have trouble. Obviously "you" in this sentence is not
Jeff King, but I think you get the point.
Clearly, because there _isn't_ anybody more clueful than me in git. ;)
But that is what my meta-rant elsewhere in the thread was about. Sure,
it hurts when more clueful people are called in (and that includes
asking for help on the list). But that evil to me is much less than a
user who is frustrated because they have to specify the same thing to
git over and over again.
quoted
And re-read what I wrote in its entirety and notice I am not disagreeing
with you that the long term goal should be to have the default changed
consistently for all command to do the full tree. The important first
step is to make sure we are capable of doing both full tree and limit to
current directory and "grep" is one example that cannot do both, and be it
the --full-tree option or new /rooted-pathspec, we need some change _now_
that is backward compatible to pave the way for later changes. We give
people convenient way to choose between the two, and _train_ them to
express which way they want _without_ having to think. After that is
achieved, the default does not matter much and we can safely change the
default.
Think of it as a way to force existing users _unlearn_ the command
specific default we currently have. Because any change of default will
hurt them until that is done, we should start training them as early as
possible.
I agree with all of this as far as changing the default goes. But the
point of my earlier messages was that I don't think there _is_ one sane
default. I really do want it different per-project. And that means a
configuration option.
Since grep is so useful, both interactively and scripted, outside of
git, this is a pretty convincing argument that git-grep, and all other
git commands with configurable behavior or defaults that change over
time, need a both a scripting form and an interactive form.
From: Jeff King <hidden> Date: 2016-06-15 22:47:46
On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:
quoted
I agree with all of this as far as changing the default goes. But the
point of my earlier messages was that I don't think there _is_ one sane
default. I really do want it different per-project. And that means a
configuration option.
Since grep is so useful, both interactively and scripted, outside of
git, this is a pretty convincing argument that git-grep, and all
other git commands with configurable behavior or defaults that change
over time, need a both a scripting form and an interactive form.
It is tempting to have scripts simply set a GIT_VANILLA environment
variable to ignore config options. But I think it is not quite so
simple. As a script, if I am calling "git log", do I want it to respect
the user's colorization config or not? It depends on _how_ I am calling
it. Is the output to be shown to the user, or am I going to process it
myself?
Similarly, why is the script calling "git grep"? If it is because the
script is a convenience wrapper (e.g., let's say to colorize the output
in a particular way), then it probably wants to respect my configured
choice of which files to grep. But if the script is just using "git
grep" to get data to perform some other calculation, then it probably
does care deeply about which set of files to grep.
So I think you have situations where scripts do want to invoke the
porcelain version of a command versus the plumbing. But much harder, you
have ones where they want to respect some options but not others.
-Peff
From: A Large Angry SCM <hidden> Date: 2016-06-15 22:47:46
Jeff King wrote:
On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:
quoted
quoted
I agree with all of this as far as changing the default goes. But the
point of my earlier messages was that I don't think there _is_ one sane
default. I really do want it different per-project. And that means a
configuration option.
Since grep is so useful, both interactively and scripted, outside of
git, this is a pretty convincing argument that git-grep, and all
other git commands with configurable behavior or defaults that change
over time, need a both a scripting form and an interactive form.
It is tempting to have scripts simply set a GIT_VANILLA environment
variable to ignore config options. But I think it is not quite so
simple. As a script, if I am calling "git log", do I want it to respect
the user's colorization config or not? It depends on _how_ I am calling
it. Is the output to be shown to the user, or am I going to process it
myself?
Similarly, why is the script calling "git grep"? If it is because the
script is a convenience wrapper (e.g., let's say to colorize the output
in a particular way), then it probably wants to respect my configured
choice of which files to grep. But if the script is just using "git
grep" to get data to perform some other calculation, then it probably
does care deeply about which set of files to grep.
So I think you have situations where scripts do want to invoke the
porcelain version of a command versus the plumbing. But much harder, you
have ones where they want to respect some options but not others.
<semi rhetorical>
So, what's the solution?
Have every command command take a list of configuration options to
ignore/respect?
Have every command take an option to ignore/respect _all_ configuration
options?
Have inconsistency between commands, like we have now
Have commands have all kinds of hidden/undocumented default settings?
</semi rhetorical>
From: Jeff King <hidden> Date: 2016-06-15 22:47:46
On Wed, Nov 25, 2009 at 06:07:00PM -0500, A Large Angry SCM wrote:
<semi rhetorical>
So, what's the solution?
Have every command command take a list of configuration options to
ignore/respect?
Have every command take an option to ignore/respect _all_
configuration options?
Have inconsistency between commands, like we have now
Have commands have all kinds of hidden/undocumented default settings?
</semi rhetorical>
I don't know. All of those options suck. ;
Probably we would want something flexible, but with sane defaults. Like
an environment variable to ignore all (or most) config options, but then
the ability to opt into specific ones. Something like:
GIT_PLUMBING=1; export GIT_PLUMBING
git log ;# does not respect any non-plumbing config
git --respect='log.showroot' ;# respect just the one variable
git --respect='color.*' log ;# you get all color
But there are two big obstacles (besides the obvious issue that
introducing this in itself needs a gentle transition plan):
1. We need to annotate every config option with whether it is
potentially problematic. For example, core.filemode should probably
be respected no matter what (but I'm not sure if it is simply true
for core.*).
2. Script writers need to actually use the system, which is somewhat
more verbose and annoying than what they have to do now. But at
least it defaults to safety when they are lazy, and then they can
re-add options. Of course, they are stuck on an upgrade treadmill
of analyzing and approving each new option that appears in git.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 22:47:47
On Thu, Nov 26, 2009 at 1:22 AM, Jeff King [off-list ref] wrote:
Probably we would want something flexible, but with sane defaults. Like
an environment variable to ignore all (or most) config options, but then
the ability to opt into specific ones. Something like:
GIT_PLUMBING=1; export GIT_PLUMBING
git log ;# does not respect any non-plumbing config
git --respect='log.showroot' ;# respect just the one variable
git --respect='color.*' log ;# you get all color
But there are two big obstacles (besides the obvious issue that
introducing this in itself needs a gentle transition plan):
1. We need to annotate every config option with whether it is
potentially problematic. For example, core.filemode should probably
be respected no matter what (but I'm not sure if it is simply true
for core.*).
2. Script writers need to actually use the system, which is somewhat
more verbose and annoying than what they have to do now. But at
least it defaults to safety when they are lazy, and then they can
re-add options. Of course, they are stuck on an upgrade treadmill
of analyzing and approving each new option that appears in git.
+1 on this.
This would make it easier to add options in the future that would be
potentially dangerous to scripts otherwise. But more than
"non-plumbing" I would rather define these variables as *preferences*;
things that are not essential to the proper functioning of git
commands, and would vary from user to user.
--
Felipe Contreras
From: Uri Okrent <hidden> Date: 2016-06-15 22:47:47
Felipe Contreras wrote:
On Thu, Nov 26, 2009 at 1:22 AM, Jeff King [off-list ref] wrote:
quoted
Probably we would want something flexible, but with sane defaults. Like
an environment variable to ignore all (or most) config options, but then
the ability to opt into specific ones. Something like:
GIT_PLUMBING=1; export GIT_PLUMBING
git log ;# does not respect any non-plumbing config
git --respect='log.showroot' ;# respect just the one variable
git --respect='color.*' log ;# you get all color
But there are two big obstacles (besides the obvious issue that
introducing this in itself needs a gentle transition plan):
1. We need to annotate every config option with whether it is
potentially problematic. For example, core.filemode should probably
be respected no matter what (but I'm not sure if it is simply true
for core.*).
2. Script writers need to actually use the system, which is somewhat
more verbose and annoying than what they have to do now. But at
least it defaults to safety when they are lazy, and then they can
re-add options. Of course, they are stuck on an upgrade treadmill
of analyzing and approving each new option that appears in git.
+1 on this.
This would make it easier to add options in the future that would be
potentially dangerous to scripts otherwise. But more than
"non-plumbing" I would rather define these variables as *preferences*;
things that are not essential to the proper functioning of git
commands, and would vary from user to user.
Sounds like a good idea to me, speaking as someone who has git support
scripts. Dealing with configuration soup in every script would be very
bad.
The same type of insulation though could probably be achieved by not
adding configuration options that alter the behavior of commands,
and instead have user's rely on aliases for that purpose. (The cat's
probably already out of the bag WRT to configuration though).
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/