Re: [PATCH] grep: --full-tree

Jeff King [off-list ref] writes:

On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:

quoted

So I think the posted patch alone without changing anything else would be
the approach to give the most benefit with the least impact to existing
users, at least for now.

Yes, I meant to say in my original message but forgot to: I think
--full-tree is an important first step, no matter what happens next. It
gives people a way to do what they want without typing the right number
of ".."s, and it opens up --no-full-tree if the default changes later.

But I do worry about it being a command-line option. You are asking the
user to remember to type --full-tree every time.

We could redefine get_pathspec() to treat a pathspec that begins with a
slash to be anchored at the top, i.e.

	$ git grep -e frotz /

would be a nicer way to spell

	$ git grep --full-tree -e frotz

and allows you more than what you can do with --full-tree, e.g.

	$ cd linux/subtree/some/very/deep/subdir/you/do/not/remember/exactly
	$ git grep -e frotz /linux/subtree

If we do that, it will not be limited to "grep" but would bring uniformity
to the command set [*1*].  Of course, you can keep doing

	$ cd t
	$ git grep -e frotz .

to look inside only the current directory, and once this new convention is
accepted and widely used, it would become possible to flip the default
without causing too much pain (yes, I am agreeing with you that this is an
important first step).

Once there is a convenient and uniform way to ask for either behaviour, no
matter what the default is, the scripts that want specific behaviour can
be updated to choose whichever they want, given enough time (say, 2.0.0).

Certainly I think that would be an improvement. But again, it suffers
from the "you must remember to do this" as above. I really want "git
grep" to Do What I Mean.

And /this-is-absolute is one way to tell "grep" What You Mean.  I do not
claim it would be the _best_ way (I just concocted it up a few minutes ago
without giving it deep thought).  Do you have a better alternative in
mind?

I have to wonder: is "git grep" really plumbing or porcelain? It is
really just a wrapper for

  git ls-files | xargs grep

Do people actually use it in their scripts? Should they be?

The issue is not necessarily "scripts", but "what people use the output
for".

My earlier "push is excusable" was primarily because "push" tends to be
the _final_ action in the chain of events, as opposed to "ls-files" and
"grep" output that are meant to be used by the user to _decide_ what to
do next depending on what they find, and as such, the latter has more
problem if they changed behaviour based on the configuration.


[Footnote]

*1* It won't be only get_pathspec(), but we would also need to teach
verify_filename() and verify_non_filename() about the new convention.

On Wed, Nov 25, 2009 at 01:33:22PM -0800, Junio C Hamano wrote:

We could redefine get_pathspec() to treat a pathspec that begins with a
slash to be anchored at the top, i.e.

	$ git grep -e frotz /

would be a nicer way to spell

	$ git grep --full-tree -e frotz

I do like that idea (and I cannot see any obvious flaw in it, though I
have only been think for a few minutes). I am not sure how useful it
will be for other commands. Conceptually I might use it for "diff" and
"status" (the new version that uses pathspecs sanely :) ), but those
commands generally aren't a big deal. I haven't touched anything in the
uninteresting subtree, so there is nothing to report.

Hmm. Actually, after having considered that, don't we actually allow
absolute paths in diff to do out-of-tree diffs? I haven't looked at how
that code interacts with get_pathspec.

quoted

Certainly I think that would be an improvement. But again, it suffers
from the "you must remember to do this" as above. I really want "git
grep" to Do What I Mean.

And /this-is-absolute is one way to tell "grep" What You Mean.  I do not
claim it would be the _best_ way (I just concocted it up a few minutes ago
without giving it deep thought).  Do you have a better alternative in
mind?

Well, what I meant is that I shouldn't have to tell it each time what I
mean. I should be able to set up configuration so that it does what I
want (well, ideally, it would just read my mind, but I am willing to
concede that point). That is, I don't want to have to remember "git grep
--full-tree" or "git grep /" every time, because I am not likely to
notice when I forget. I want to set up "when I am in this directory,
this is probably what I want".

My earlier "push is excusable" was primarily because "push" tends to be
the _final_ action in the chain of events, as opposed to "ls-files" and
"grep" output that are meant to be used by the user to _decide_ what to
do next depending on what they find, and as such, the latter has more
problem if they changed behaviour based on the configuration.

I'm not sure I really understand. "git grep" is routinely producing
wrong results for me _now_. I'd like to configure it so that it produces
results more sensible to me. If I am the one who sets the configuration
variable to something more sensible for my workflow, who am I hurting?

-Peff

On Wed, Nov 25, 2009 at 2:49 PM, Jeff King [off-list ref] wrote:

I'm not sure I really understand. "git grep" is routinely producing
wrong results for me _now_. I'd like to configure it so that it produces
results more sensible to me. If I am the one who sets the configuration
variable to something more sensible for my workflow, who am I hurting?

Config options are not free - they add code bloat, increase the maintenance
and testing burden, make it harder to explain how Git works if you have to
say things like "if config X is true, then Git does ..., otherwise Git does
..., unless config Y is false, in which case Git does ...", make it harder
to debug when Git doesn't do what you expected if you have to check a bunch
of configs to figure out what the behavior should be, and make it harder to
develop new features since you have to consider how they might interact with
lots of config options.  So I think the bar for adding config options,
especially ones that fundamentally change user visible behavior, should be
set pretty high, and this one doesn't even come close to getting over the
bar.

I like Junio's suggestion to make paths starting with / anchored to the
top.  If that were added then it would be easy for users to tell Git what
they want; they just have to use the right pathspec, which I think is a
very reasonable requirement.

That's my 2 cents....

James

Junio C Hamano wrote:
 > Jeff King [off-list ref] writes:
 >
 >> On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:
 >>
 >>> So I think the posted patch alone without changing anything else 
would be
 >>> the approach to give the most benefit with the least impact to existing
 >>> users, at least for now.
 >> Yes, I meant to say in my original message but forgot to: I think
 >> --full-tree is an important first step, no matter what happens next. It
 >> gives people a way to do what they want without typing the right number
 >> of ".."s, and it opens up --no-full-tree if the default changes later.
 >>
 >> But I do worry about it being a command-line option. You are asking the
 >> user to remember to type --full-tree every time.
 >
 > We could redefine get_pathspec() to treat a pathspec that begins with a
 > slash to be anchored at the top, i.e.
 >
 > 	$ git grep -e frotz /
 >
 > would be a nicer way to spell
 >
 > 	$ git grep --full-tree -e frotz
 >
 > and allows you more than what you can do with --full-tree, e.g.
 >
 > 	$ cd linux/subtree/some/very/deep/subdir/you/do/not/remember/exactly
 > 	$ git grep -e frotz /linux/subtree
 >
 > If we do that, it will not be limited to "grep" but would bring 
uniformity
 > to the command set [*1*].  Of course, you can keep doing
 >
 > 	$ cd t
 > 	$ git grep -e frotz .
 >
 > to look inside only the current directory, and once this new 
convention is
 > accepted and widely used, it would become possible to flip the default
 > without causing too much pain (yes, I am agreeing with you that this 
is an
 > important first step).
 >
 > Once there is a convenient and uniform way to ask for either 
behaviour, no
 > matter what the default is, the scripts that want specific behaviour can
 > be updated to choose whichever they want, given enough time (say, 2.0.0).
 >

Speaking as a `grep' user: having git-grep behave radically different 
than normal grep would be/is very annoying [*1*].

Speaking as a `git' user: having the different git commands use 
radically different path conventions, relative to other git commands, 
would be/is very annoying [*1*].

To make the reconciliation  even more difficult, some git commands will 
also work on out-of-tree paths.

Footnotes:
[*1*] And surprising to new/occasional git users.

On Wed, Nov 25, 2009 at 03:12:26PM -0700, James Pickens wrote:

Config options are not free - they add code bloat, increase the maintenance
and testing burden, make it harder to explain how Git works if you have to
say things like "if config X is true, then Git does ..., otherwise Git does
..., unless config Y is false, in which case Git does ...", make it harder
to debug when Git doesn't do what you expected if you have to check a bunch
of configs to figure out what the behavior should be, and make it harder to
develop new features since you have to consider how they might interact with
lots of config options.  So I think the bar for adding config options,
especially ones that fundamentally change user visible behavior, should be
set pretty high, and this one doesn't even come close to getting over the
bar.

Sure, there are all those downsides. But what is the other option?
Making me use the command line option (or pathspec magic) every single
time I invoke git grep? That is a huge downside to me.

I started to try to write an argument against this, but I really don't
know how to. You don't think this particular option gets over the bar.
Probably because it is not something that has been annoying you
personally. But is _is_ something that has been annoying me. Now we are
both making claims from our gut. How do we proceed with a rational
analysis?

-Peff

El 25/11/2009, a las 23:12, James Pickens escribió:

I like Junio's suggestion to make paths starting with / anchored to  
the
top.

Oh, I wouldn't like that at all. I think it would be a very ugly UI  
wart, because it would basically make Git behave differently than  
every other command line tool that accepts paths. If it is to deviate  
from the extremely widespread convention that paths starting with /  
refer to absolute paths rooted at the root of the filesystem, then the  
justification for it would need to be very strong indeed.

Cheers,
Wincent

Hi,

On Wed, 25 Nov 2009, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:

quoted

So I think the posted patch alone without changing anything else would be
the approach to give the most benefit with the least impact to existing
users, at least for now.

Yes, I meant to say in my original message but forgot to: I think
--full-tree is an important first step, no matter what happens next. It
gives people a way to do what they want without typing the right number
of ".."s, and it opens up --no-full-tree if the default changes later.

But I do worry about it being a command-line option. You are asking the
user to remember to type --full-tree every time.

We could redefine get_pathspec() to treat a pathspec that begins with a
slash to be anchored at the top,

This would break spectacularly in MSys.  And this is just one reason not 
to do this "magic".

Clearly, a command line option is the only unambiguous way to do what you 
want to do (and not changing the default all of a sudden).

Ciao,
Dscho

On Wed, Nov 25, 2009 at 3:20 PM, Jeff King [off-list ref] wrote:

Sure, there are all those downsides. But what is the other option?
Making me use the command line option (or pathspec magic) every single
time I invoke git grep?

Yes, but only when you want non-default behavior, not every single time.

That is a huge downside to me.

Is it *really*?  Does it also bother you that you have to tell standalone
unix commands like diff and grep what you want them to diff or grep every
single time you invoke them?

I started to try to write an argument against this, but I really don't
know how to. You don't think this particular option gets over the bar.
Probably because it is not something that has been annoying you
personally. But is _is_ something that has been annoying me. Now we are
both making claims from our gut. How do we proceed with a rational
analysis?

I really think that this config option wouldn't even help you, because
you'll have to remember what that option is set to in each working repo,
and type the right command based on the setting.  That seems worse than
having to use the same options over and over again, which you probably use
the shell's history for anyways and don't actually type the same stuff over
and over.  Oh and you also have to remember to set the option in each new
repo you create.

If you can get the behavior you want using an alias or a script, then I
suggest you do that.  I don't think this config option should be considered
unless *many* people want it, and so far I count only 1.

James

On Thu, Nov 26, 2009 at 10:56:55AM -0700, James Pickens wrote:

On Wed, Nov 25, 2009 at 3:20 PM, Jeff King [off-list ref] wrote:

quoted

Sure, there are all those downsides. But what is the other option?
Making me use the command line option (or pathspec magic) every single
time I invoke git grep?

Yes, but only when you want non-default behavior, not every single time.

Did you miss the part of the thread where I explained that in certain
repos, I want it one way every single time, and in others, I want it the
other way?

So yes, in certain repos, it really is every single time.

quoted

That is a huge downside to me.

Is it *really*?  Does it also bother you that you have to tell standalone
unix commands like diff and grep what you want them to diff or grep every
single time you invoke them?

This is a strawman. I am not saying every command-line option should be
made into a configuration option. I am saying that some options,
including this one, would be useful as configuration options. I have
already explained several times in this thread exactly what
characteristics of this option make that so.

And please, questions like "Is it *really*?" don't add anything. Yes,
really, or I wouldn't be having this discussion. This behavior has
bitten me many times while using "git grep". I'm not making it up. Maybe
I am the only one in the world, but I don't see how it makes any sense
to argue that I am not actually annoyed by it.

I really think that this config option wouldn't even help you, because
you'll have to remember what that option is set to in each working repo,
and type the right command based on the setting.  That seems worse than

No, the _point_ is that I don't have to remember the right command in
each repo. I can set it up for the workflow that matches that repository
and then issue "git grep" without remembering which type I'm in.

If you can get the behavior you want using an alias or a script, then I
suggest you do that.  I don't think this config option should be considered
unless *many* people want it, and so far I count only 1.

Perhaps I am the only one who wants to use the config option per-repo.
But we have already seen support for both behaviors, which means there
are people who will be dissatisfied with either simply leaving the
default or changing the default. And I don't want to speak for Junio,
but he seemed to agree that what you most want would depend on the repo
organization (though I think he may disagree that it is important enough
to merit the hassle of a config option).

-Peff

Hi,

On Fri, 27 Nov 2009, Jeff King wrote:

On Thu, Nov 26, 2009 at 10:56:55AM -0700, James Pickens wrote:

quoted

On Wed, Nov 25, 2009 at 3:20 PM, Jeff King [off-list ref] wrote:

quoted

Sure, there are all those downsides. But what is the other option? 
Making me use the command line option (or pathspec magic) every 
single time I invoke git grep?

Yes, but only when you want non-default behavior, not every single 
time.

Did you miss the part of the thread where I explained that in certain 
repos, I want it one way every single time, and in others, I want it the 
other way?

Guess what.  I have a similar problem, only it is that my "git status" 
output is _always_ too long, so I always have to page it.

Once upon a time, Junio applied a patch that implied -p with status.  I 
was overjoyed.  He reverted that patch later.  Yes, exactly.

So I end up doing "git config --global ps '-p status'" on every new 
account (I usually even forget to curse!), and I really cannot see why you 
do not do the equivalent "git config fullgrep grep --full-tree" in your 
repositories (or even the global thing).

The further benefit is that we stop talking about breaking backwards 
compatibility, and we stop talking about making it hard for Git experts to 
help newbies.

Ciao,
Dscho

On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:

Guess what.  I have a similar problem, only it is that my "git status" 
output is _always_ too long, so I always have to page it.

Once upon a time, Junio applied a patch that implied -p with status.  I 
was overjoyed.  He reverted that patch later.  Yes, exactly.

So I end up doing "git config --global ps '-p status'" on every new 

If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.

account (I usually even forget to curse!), and I really cannot see why you 
do not do the equivalent "git config fullgrep grep --full-tree" in your 
repositories (or even the global thing).

The further benefit is that we stop talking about breaking backwards 
compatibility, and we stop talking about making it hard for Git experts to 
help newbies.

I guess you missed the part of the thread where I already discussed
this. It was here:

  http://article.gmane.org/gmane.comp.version-control.git/133672

-Peff

Hi,

On Fri, 27 Nov 2009, Jeff King wrote:

On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:

quoted

Guess what.  I have a similar problem, only it is that my "git status" 
output is _always_ too long, so I always have to page it.

Once upon a time, Junio applied a patch that implied -p with status.  
I was overjoyed.  He reverted that patch later.  Yes, exactly.

So I end up doing "git config --global ps '-p status'" on every new 

If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.

And it makes things inconsistent.  That is why I do not use it.  Do you 
work on 10 different computers?  I do.  And nothing is more unnerving than 
the same command producing something different on the different computers.

Sure, after a few minutes of fiddling I find out that it was my fault to 
begin with, but dammit! if the tool makes it that hard already for an 
expert, it is outright unusable for new users.

I, for one, do not like Git's reputation, but I am tired of trying to 
fight for the users.  BTW quick question: how many Git _users_ were at the 
GitTogether at MV?  0?

quoted

account (I usually even forget to curse!), and I really cannot see why 
you do not do the equivalent "git config fullgrep grep --full-tree" in 
your repositories (or even the global thing).

The further benefit is that we stop talking about breaking backwards 
compatibility, and we stop talking about making it hard for Git 
experts to help newbies.

I guess you missed the part of the thread where I already discussed
this. It was here:

  http://article.gmane.org/gmane.comp.version-control.git/133672

I only skimmed it, yes.  And I did not plan to participate in this thread.  
But it seems that my views are not represented enough, even if gitzilla 
chimed in with the very valid, under-acknowledged and over-ignored 
message: consistency is good.  Corollary: inconsistency is bad.

Ciao,
Dscho

I've been following this thread for a long time and now I feel the
need to chime in...

On Fri, Nov 27, 2009 at 2:53 AM, Johannes Schindelin
[off-list ref] wrote:

And it makes things inconsistent.  That is why I do not use it.

The number one problem my users have with git is inconsistent
behavior, both internally to git, and externally with respect to the
rest of the OS. But really, the issue is one of managing expectations,
which is where we here tend to fall down.

When you name the command grep, whether you like it of not,
you've bought into a certain set of expectations from the user
who has been using unix's grep since she was a baby. Saying,
"well, in git it works this way", (or saying "well in git those path
looking things you've been providing to commands are not really
paths, so don't expect them to act as such"), would make my
users want to vomit all over me, and then, not use git (a shame
since it's the best scm system around IMHO).

If we intend the behavior of the command to be materially different
from the good old unix standby, then we shouldn't use the same
name, and create the expectation that they are getting essentially
the same thing (git search, git pickaxe, or something carries no
semantic baggage---and no, I'm not suggesting we change the
name).

I, for one, do not like Git's reputation...

There's the rub. How do we achieve consistency without breaking the
world? The short answer is, you really can't. As programmers we tend
to be a very timid bunch, but sometimes (and David A. can attest to
this, at least at dayjob) it's better to just make a change for the better,
and just deal with the breakages. It is possible to change behavior (and
even break some scripts! I firmly believe it is worthwhile sacrificing
some scripts on the altar of consistency).

The key once again, is managing expectations. We can't go around
changing everything willy-nilly, and we can't be continually changing
things. Here is where we could take a lesson from the python
community.

When they decided they needed to change things, they bundled a
bunch of backwards incompatible changes together and went for it.
Yes, Python 3 will break your scripts, but the most important thing is,
everybody knows it.

A similar thing was done here with the huge warning that push spits
out, but in the general case I would argue, that the wisest course is to
save backwards incompatible changes for a git 2 or something, where
we know we're breaking the world, and then scratch all our (well thought
out) backwards incompatible itches at once.

Whew. A bit of a rant, but there you go...
-- 
   Uri

Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/

On Fri, Nov 27, 2009 at 11:53:42AM +0100, Johannes Schindelin wrote:

quoted

If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.

And it makes things inconsistent.  That is why I do not use it. 

Then you can not use this configuration variable, too. Has the existence
of pager.status, since you do not use it, been a problem for you so far?

Do you work on 10 different computers?  I do.  And nothing is more
unnerving than the same command producing something different on the
different computers.

Yes, as a matter of fact, I do work on 10 different computers. I'm sorry
that you find managing your configuration so challenging. But if you
don't use the configuration variable, then your own personal setup is
totally irrelevant.

If your argument is that this lack of consistency will irritate users,
you need to show that:

  1. There are users who switch between a large number of setups, but
     will not apply config consistently.

  2. Some of these setups will be using the new config option.

If they are all controlled by a single user, how is that user any worse
off for the config option existing? They can choose not to use it if
the hassle is not worth it. I do not think the existence of an option is
giving too much rope to these users.

If you are talking about 10 machines, all controlled by different users,
whose terminals you have to sit down on to help them, then yes, it will
be inconvenient for you. But if users are setting up configuration for
these machines, shouldn't _their_ convenience in using configuration
trump _your_ convenience for occasionally sitting down and helping them?

I, for one, do not like Git's reputation, but I am tired of trying to 
fight for the users.  BTW quick question: how many Git _users_ were at the 
GitTogether at MV?  0?

In my opinion, you are actively fighting _against_ a user in this case.

And the GitTogether had a "users complain about git, and we try to
listen" session. There were two google users in person, but we also went
through a list of pre-made questions from other googlers. This issue
wasn't discussed, though. Nor was the question of consistency between
configurations, to my recollection. I think Shawn may have taken notes,
and could be more specific.

quoted

  http://article.gmane.org/gmane.comp.version-control.git/133672

I only skimmed it, yes.  And I did not plan to participate in this thread.  
But it seems that my views are not represented enough, even if gitzilla 
chimed in with the very valid, under-acknowledged and over-ignored 
message: consistency is good.  Corollary: inconsistency is bad.

That is an over-simplification. Inconsistency between setups is bad. But
so is inconsistency between git commands, and between git and other
commands. So is not supporting a user's workflow, or supporting it in a
way that is tedious and error-prone. You have to weigh the badness of
those things against each other in finding a solution.

But then, that was the point I already made in the article linked above.

-Peff

Jeff King [off-list ref] writes:

On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:

quoted

Guess what.  I have a similar problem, only it is that my "git status" 
output is _always_ too long, so I always have to page it.

Once upon a time, Junio applied a patch that implied -p with status.  I 
was overjoyed.  He reverted that patch later.  Yes, exactly.

It would have been more fair to me if Dscho said "He had to revert", to
hint that it was not due to me changing the preference left and right on a
whim.

quoted

So I end up doing "git config --global ps '-p status'" on every new 

If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.

Nice try but, "grep" and "status" are apples and oranges comparision.

A "status" command that pages or does not page the output only when
spitting out to a terminal won't hurt somebody who helps another with the
configuration set differently, as much as a "grep" that shows or not shows
matches from other parts of the tree would, and when used by a script to
make a decision based on the output, the caller has to capture the output
first, and unless the caller drives "status" via pty, e.g. using "expect",
paging behaviour will be disabled no matter what the configuration setting
is.

So neither "it would hurt people who help others" nor "it would hurt
scripts" would apply to "status".  But both would apply to "grep".

quoted

The further benefit is that we stop talking about breaking backwards 
compatibility, and we stop talking about making it hard for Git experts to 
help newbies.

I guess you missed the part of the thread where I already discussed
this. It was here:

  http://article.gmane.org/gmane.comp.version-control.git/133672

This was a very good summary, and was one of the reasons that made me
reconsider placing too much weight on "it would hurt people who help
others" (but not on "it would hurt scripts").

Uri Okrent [off-list ref] writes:

The key once again, is managing expectations. We can't go around
changing everything willy-nilly, and we can't be continually changing
things. Here is where we could take a lesson from the python
community.

When they decided they needed to change things, they bundled a
bunch of backwards incompatible changes together and went for it.
Yes, Python 3 will break your scripts, but the most important thing is,
everybody knows it.

A similar thing was done here with the huge warning that push spits
out, but in the general case I would argue, that the wisest course is to
save backwards incompatible changes for a git 2 or something, where
we know we're breaking the world, and then scratch all our (well thought
out) backwards incompatible itches at once.

You preach to the choir.

That is exactly how we work and what people have been working hard for
1.7.0.  Check the planned changes listed in the recent (and not so recent)
"What's cooking" summary reports.

Changing "grep" is too late for 1.7.0, but we are trying to find an easy
migration path like you mentioned in your message and that is exactly what
this thread is about.

Junio C Hamano wrote:

You preach to the choir.

That is exactly how we work and what people have been working hard for
1.7.0.  Check the planned changes listed in the recent (and not so recent)
"What's cooking" summary reports.

Yes, I guess my only point here was that maybe even 1.7 is not enough of
a "Big Deal" (in the eyes of the public) to warrant breaking scripts. A
2.0 version would be a more visible way to say "Hey test your scripts
before upgrading". Adopting a strategy like that would mean making
backwards incompatible changes a lot let frequently, but when we do we
go for broke.

Changing "grep" is too late for 1.7.0, but we are trying to find an easy
migration path like you mentioned in your message and that is exactly what
this thread is about.

I wasn't actually suggesting we change grep for 1.7. As a matter of
fact, my personal opinion (which I probably neglected to mention) is
that grep default behavior should stay the same since it is semantically
closer to unix (or gnu) grep.

-- 
    Uri

Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/

Hi,

On Fri, 27 Nov 2009, Jeff King wrote:

On Fri, Nov 27, 2009 at 11:53:42AM +0100, Johannes Schindelin wrote:

quoted

quoted

If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.

And it makes things inconsistent.  That is why I do not use it. 

Then you can not use this configuration variable, too. Has the existence
of pager.status, since you do not use it, been a problem for you so far?

No, since none of the people I helped use it.

quoted

Do you work on 10 different computers?  I do.  And nothing is more 
unnerving than the same command producing something different on the 
different computers.

Yes, as a matter of fact, I do work on 10 different computers. I'm sorry 
that you find managing your configuration so challenging. But if you 
don't use the configuration variable, then your own personal setup is 
totally irrelevant.

As I just demonstrated, this is a false statement.

If your argument is that this lack of consistency will irritate users,
you need to show that:

  1. There are users who switch between a large number of setups, but
     will not apply config consistently.

This is a strawman, and you should be ashamed to put it here.  Just 
because nobody does what you actively encourage does not mean that the 
encouraged procedure is good, or for that matter, helps anybody but you.

Just think about it.  If you plan to change the side cars are supposed to 
drive on, it is not enough to have a nice cozy committee deciding on it in 
some little room somewhere in Wyoming.  Especially not if they decide that 
you can drive on the other side if you put a sticker "I am a right-wing 
driver" on your car.

It is inconsistent, and it is violating the law of the least surprise.

And the GitTogether had a "users complain about git, and we try to
listen" session.

Oh, that makes me so happy.  <sarcasm>Soooo happy</sarcasm>.  So it was an 
ivory tower meeting, once again?

Ciao,
Dscho

On Fri, Nov 27, 2009 at 10:29:11AM -0800, Junio C Hamano wrote:

quoted

If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.

Nice try but, "grep" and "status" are apples and oranges comparision.

Yes, I think you are right that the existence of pager.* does not
necessarily imply that there should be a config option for grep. But
that makes his example even more irrelevant: he is advocating that I use
a solution in this instance because he uses it in another instance, when
that solution is not even necessary in the other instance (and as I have
hopefully already made clear, is in my opinion inferior).

It is probably better to stay on the topic of the grep option, though.

-Peff

On Fri, Nov 27, 2009 at 10:47:45AM -0800, Uri Okrent wrote:

quoted

Changing "grep" is too late for 1.7.0, but we are trying to find an easy
migration path like you mentioned in your message and that is exactly what
this thread is about.

I wasn't actually suggesting we change grep for 1.7. As a matter of
fact, my personal opinion (which I probably neglected to mention) is
that grep default behavior should stay the same since it is semantically
closer to unix (or gnu) grep.

Keeping consistency with non-git grep has been mentioned a few times in
this thread.  I really don't understand how default file selection is
supposed to maintain consistency with non-git grep. Regular grep
defaults to stdin if no paths are given. That mode doesn't make any
sense for git grep.

So of the two options (grepping the list of files from the full tree, or
the list of files rooted at the current directory), how is one closer to
non-git grep than the other?

-Peff

On Fri, Nov 27, 2009 at 09:07:51PM +0100, Johannes Schindelin wrote:

quoted

Yes, as a matter of fact, I do work on 10 different computers. I'm sorry 
that you find managing your configuration so challenging. But if you 
don't use the configuration variable, then your own personal setup is 
totally irrelevant.

As I just demonstrated, this is a false statement.

I must have missed where you demonstrated it.

quoted

If your argument is that this lack of consistency will irritate users,
you need to show that:

  1. There are users who switch between a large number of setups, but
     will not apply config consistently.

This is a strawman, and you should be ashamed to put it here.  Just 

How is this a strawman? A strawman would be me overstating an
exaggerated position by you and then arguing against it. All I have
claimed is that it is not sufficient for _you_ to be personally annoyed
by this existence of this option. You need to argue that there is a
significant group of people in the same situation who will be ignored.

Or have I mis-spoken in summarizing your claim that a "lack of
consistency will irritate users". Is that not your point?

Just think about it.  If you plan to change the side cars are supposed to 
drive on, it is not enough to have a nice cozy committee deciding on it in 
some little room somewhere in Wyoming.  Especially not if they decide that 
you can drive on the other side if you put a sticker "I am a right-wing 
driver" on your car.

When the number of "git grep" crash fatalities rises above zero, maybe
this line of reasoning will be relevant.

I am talking about making software configurable so that people, in their
own private setups, can make the software work as they see fit. Yes, it
is possible for that setup to be visible to other people in some
situations. But I am arguing that we need to weigh the (in my opinion
substantial) inconvenience to users in their everyday work compared to
the inconvenience of one user sitting at another user's terminal (or
cutting and pasting commands, or running a script).

quoted

And the GitTogether had a "users complain about git, and we try to
listen" session.

Oh, that makes me so happy.  <sarcasm>Soooo happy</sarcasm>.  So it was an 
ivory tower meeting, once again?

I don't know what to say. You complain and complain about how git is not
being responsive to users. Shawn organizes a session where people at
Google who are using git every day can try to make their complaints in
an organized forum where a bunch of developers will listen and talk
about ways we can address those complaints. And now you are mad about
that?

If you think we need a git conference where lots of users show up, I
think that's a great idea. But until you provide some suggestions about
how to organize such a thing, I don't see how you are helping anything.

-Peff

Hi,

On Fri, 27 Nov 2009, Jeff King wrote:

On Fri, Nov 27, 2009 at 10:29:11AM -0800, Junio C Hamano wrote:

quoted

quoted

If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.

Nice try but, "grep" and "status" are apples and oranges comparision.

Yes, I think you are right that the existence of pager.* does not
necessarily imply that there should be a config option for grep. But
that makes his example even more irrelevant: he is advocating that I use
a solution in this instance because he uses it in another instance, when
that solution is not even necessary in the other instance (and as I have
hopefully already made clear, is in my opinion inferior).

Sorry, no, you got it all wrong.

My point was that your config option introduced something _BAD_.  And my 
point was that now, as a consequence of having managed to put it into Git, 
you want more of such bad stuff.

You continue to ignore that inconsistency -- even if it is introduced with 
the best of all intentions -- is bad, bad, bad.

But I guess that I continue to get ignored,
Dscho

Hi,

On Fri, 27 Nov 2009, Jeff King wrote:

On Fri, Nov 27, 2009 at 09:07:51PM +0100, Johannes Schindelin wrote:

quoted

quoted

Yes, as a matter of fact, I do work on 10 different computers. I'm sorry 
that you find managing your configuration so challenging. But if you 
don't use the configuration variable, then your own personal setup is 
totally irrelevant.

As I just demonstrated, this is a false statement.

I must have missed where you demonstrated it.

Usually, my mails are minimal, and I do not write as many mails as I 
used to anymore, so it is hard to miss what I am saying.

For your benefit: both Junio and me talked about experts helping users.  
Even if I do not use the config options, I am affected.  And it does hurt.

quoted

quoted

If your argument is that this lack of consistency will irritate users,
you need to show that:

  1. There are users who switch between a large number of setups, but
     will not apply config consistently.

This is a strawman, and you should be ashamed to put it here.  Just 

How is this a strawman?

You are comparing config settings which must be different, because they 
affect _what_ project you are working with, with config settings that 
affect _how_ you can work with them.

When the number of "git grep" crash fatalities rises above zero, maybe 
this line of reasoning will be relevant.

Sure.  Let's wait for the first crash fatality, and only react then.  No 
need to think ahead.

That's it.  I don't think that I want to participate in this kind of 
discussion anymore,
Dscho

On Fri, Nov 27, 2009 at 8:29 PM, Junio C Hamano [off-list ref] wrote:

That is exactly how we work and what people have been working hard for
1.7.0.  Check the planned changes listed in the recent (and not so recent)
"What's cooking" summary reports.

Changing "grep" is too late for 1.7.0, but we are trying to find an easy
migration path like you mentioned in your message and that is exactly what
this thread is about.

How about this. For now, make --full-tree available, and that's it.
Then, on 1.8.0, add the configuration option, and if there's consensus
make it default (-1 from me).

However, in order to ease the transition I think Jeff's GIT_PLUMBING
(I would call it GIT_SCRIPTING) should be introduced on 1.7.0 so
people can start exporting it in their scripts. That way people don't
have to worry about adding --(no-)full-tree on their scripts (nor any
other argument that depends on configurations) and when 1.8.0 comes,
there's no script breakage.

-- 
Felipe Contreras

On Fri, Nov 27, 2009 at 10:07 PM, Johannes Schindelin
[off-list ref] wrote:

On Fri, 27 Nov 2009, Jeff King wrote:

quoted

Yes, as a matter of fact, I do work on 10 different computers. I'm sorry
that you find managing your configuration so challenging. But if you
don't use the configuration variable, then your own personal setup is
totally irrelevant.

As I just demonstrated, this is a false statement.

Yes, defaults are important in UI.

quoted

If your argument is that this lack of consistency will irritate users,
you need to show that:

  1. There are users who switch between a large number of setups, but
     will not apply config consistently.

This is a strawman, and you should be ashamed to put it here.  Just
because nobody does what you actively encourage does not mean that the
encouraged procedure is good, or for that matter, helps anybody but you.

Not to mention that it's completely irrelevant. The fact that all
users apply their configurations consistently through their setups, or
not, doesn't make a default preference better or worst.

If the argument is that default preferences are not relevant enough,
then step aside and let the people that care about default preferences
to discuss.

quoted

And the GitTogether had a "users complain about git, and we try to
listen" session.

Oh, that makes me so happy.  <sarcasm>Soooo happy</sarcasm>.  So it was an
ivory tower meeting, once again?

This is very typical on many open source projects. I think the
benevolent dictator model works pretty good on low-level stuff, but on
UI I think a democratic model works better.

I've been thinking on setting up a pseudo-project on SourceForge and
setup an IdeaTorrent, that way users can generate and organize ideas
so that developers can have meaningful conversations with users:
http://brainstorm.ubuntu.com/

What do you think?

-- 
Felipe Contreras

On Sun, Nov 29, 2009 at 11:21:06AM +0100, Johannes Schindelin wrote:

You continue to ignore that inconsistency -- even if it is introduced with 
the best of all intentions -- is bad, bad, bad.

But I guess that I continue to get ignored,

Speaking of ignoring, you have never once responded to my repeated point
that I agree that inconsistency is bad, but it is about weighing that
bad against other bad things.

-Peff

On Sun, Nov 29, 2009 at 11:28:27AM +0100, Johannes Schindelin wrote:

quoted

quoted

quoted

Yes, as a matter of fact, I do work on 10 different computers. I'm sorry 
that you find managing your configuration so challenging. But if you 
don't use the configuration variable, then your own personal setup is 
totally irrelevant.

As I just demonstrated, this is a false statement.

I must have missed where you demonstrated it.

Usually, my mails are minimal, and I do not write as many mails as I 
used to anymore, so it is hard to miss what I am saying.

For your benefit: both Junio and me talked about experts helping users.  
Even if I do not use the config options, I am affected.  And it does hurt.

A point which I adressed in my numbered point (2) in the mail you are
quoting above. But you didn't bother to quote that part.

quoted

When the number of "git grep" crash fatalities rises above zero, maybe 
this line of reasoning will be relevant.

Sure.  Let's wait for the first crash fatality, and only react then.  No 
need to think ahead.

You missed my point. My point is that your analogy had many
characteristics that do not apply to this situation. You are comparing a
situation where somebody's preference (to drive on the left side or the
right side) is weighed against a system where everyone needs to follow
the same rule, or people will die in large numbers. The actual situation
at hand is a git grep configuration variable. I am weighing the
preference of people who use git every day and want it to work in a
certain way against the possibility that somebody helping them will be
slightly inconvenienced or surprised. Something that will happen much
less frequently than the person actually _using_ git, and something
which has much smaller negative consequences than people dying.

That's it.  I don't think that I want to participate in this kind of 
discussion anymore,

Fine. I have made my point over and over, and not once have you
responded to it directly, so I also feel this is going nowhere.

-Peff

Jeff King wrote:

On Fri, Nov 27, 2009 at 10:47:45AM -0800, Uri Okrent wrote:

quoted

As a matter of
fact, my personal opinion (which I probably neglected to mention) is
that grep default behavior should stay the same since it is semantically
closer to unix (or gnu) grep.

Keeping consistency with non-git grep has been mentioned a few times in
this thread.  I really don't understand how default file selection is
supposed to maintain consistency with non-git grep. Regular grep
defaults to stdin if no paths are given. That mode doesn't make any
sense for git grep.

So of the two options (grepping the list of files from the full tree, or
the list of files rooted at the current directory), how is one closer to
non-git grep than the other?

-Peff

I guess you're right, in that neither is exactly the same as non-git,
and so it's impossible to objectively quantify how one is "closer". My
general feeling though is that grep rooted at the current directory is
more similar because grep -r does exist and is common enough that the
layman isn't too surprised at git's default behavior. Git grep with
--full-tree though, has no analogue in non-git grep.

-- 
    Uri

Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/