Re: [WARNING] Proposed future changes that are backward incompatible

There's one more change that was suggested that I'd like to propose:
- Make "git grep" search the whole repository by default; include an
  explicit "." path limiter to search only the current directory.

In addition to being more consistent with other commands like "git log", this saves a lot of typing working in drivers/net/usb/ if the identifier you're looking for is in include/. Typing the additional space-dot is pretty trivial if you want the current directory only.

On Fri, 27 Feb 2009, George Spelvin wrote:

Isn't that already the default?

[nico@xanadu git]$ git grep Alice Documentation/gittutorial.txt:Suppose that Alice has started a new project with a git repository in Documentation/gittutorial.txt:This creates a new directory "myrepo" containing a clone of Alice's Documentation/gittutorial.txt:When he's ready, he tells Alice to pull changes from the repository Documentation/gittutorial.txt:This merges the changes from Bob's "master" branch into Alice's Documentation/gittutorial.txt:current branch. If Alice has made her own changes in the meantime, Documentation/gittutorial.txt:Note that in general, Alice would want her local changes committed before Documentation/gittutorial.txt:initiating this "pull". If Bob's work conflicts with what Alice did since Documentation/gittutorial.txt:their histories forked, Alice will use her working tree and the index to Documentation/gittutorial.txt:refuse to merge --- Alice will have to get rid of her local changes in Documentation/gittutorial.txt:Alice can peek at what Bob did without merging first, using the "fetch" Documentation/gittutorial.txt:command; this allows Alice to inspect what Bob did, using a special Documentation/gittutorial.txt:This operation is safe even if Alice has uncommitted local changes. Documentation/gittutorial.txt:Alice already knows everything that leads to her current state (HEAD), Documentation/gittutorial.txt:If Alice wants to visualize what Bob did since their histories forked Documentation/gittutorial.txt:Alice may want to view what both of them did since they forked. Documentation/gittutorial.txt:After inspecting what Bob did, if there is nothing urgent, Alice may Documentation/gittutorial.txt:does have something Alice would immediately need, Alice may choose to Documentation/gittutorial.txt:With this, Alice can perform the first part of the "pull" operation alone using the Documentation/gittutorial.txt:Unlike the longhand form, when Alice fetches from Bob using a Documentation/gittutorial.txt:Alice's master branch. Documentation/gittutorial.txt:After examining those changes, Alice Documentation/gittutorial.txt:Later, Bob can update his repo with Alice's latest changes using Documentation/gittutorial.txt:Note that he doesn't need to give the path to Alice's repository; Documentation/gittutorial.txt:when Bob cloned Alice's repository, git stored the location of her Documentation/gittutorial.txt:Git also keeps a pristine copy of Alice's master branch under the t/t5519-push-alternates.sh: # Project Bob is a fork of project Alice t/t5519-push-alternates.sh: # Bob acquires what Alice did in his work tree first. t/t5519-push-alternates.sh: # need to send the commit Bob received from Alice t/t5519-push-alternates.sh: # to his public repository, as all the object Alice t/t5519-push-alternates.sh: # Check that the second commit by Alice is not sent t/t5519-push-alternates.sh: # Alice does not care what Bob does. She does not t/t5519-push-alternates.sh: # This time Bob does not pull from Alice, and t/t5519-push-alternates.sh: # Alice does not care what Bob does. She does not t/t5519-push-alternates.sh: # This time Bob does not pull from Alice, and t/t5519-push-alternates.sh: # necessary tree) in his repository from Alice.

Nicolas

On Fri, Feb 27, 2009 at 20:42, Nicolas Pitre <nico@cam.org> wrote:

Now try again from within a subdir ;).

I actually prefer the current behavior, and am a very extensive user of it. Config option? ;)

Hi,

On Fri, 27 Feb 2009, George Spelvin wrote:

I use "git grep" in subdirectories extensively, and I like that it does _not_ search the whole repository.

Could you suggest a nice way for me to retain that behavior with an option?

After all, since you propose a change in behavior, it is _your_ duty to provide ways for those who want the old behavior to get at it easily!

In the alternative, I could suggest "git grep -e <expression> HEAD".

Ciao, Dscho

Johannes Schindelin a écrit :

Count me too! I find this feature very important.

Agreed.

Pascal.

"George Spelvin" <linux@horizon.com> writes:

I do not remember it was ever suggested, let alone coming to anything near consensus.

The only way you could justify such a default change is to say:

    Almost all the time, everybody wants to use this new behaviour; the
    old behaviour is almost never useful in any situation other than a
    narrow corner case; and if somebody wants to do such a useless thing
    in a corner case, he can always add " ." at the end, so nothing is
    lost.

I do not think that is true for the change you are proposing here. 'He can always add " ." at the end' alone is not a good enough justification.

I however think your use case deserves to be supported, and I would not mind at all accepting a new "--full-tree" (or some shorter synonym) option if the patch is cleanly done (hint, hint).

I'd rather not add this to "future changes that are backward incompatible" list. It may be a useful new feature, but that is not what the topic of this thread is about.

Junio C Hamano <gitster@pobox.com> wrote:

The suggestion was in <83vdsefz9j.fsf@kalahari.s2.org>, available as http://marc.info/?l=git&m=123216049508531 but I agree that there was no consensus. I just thought this thread was a good place to elicit discussion, since it would be an incompatible change.

Please forgive me, I thought the above *might* be true, and wanted to provoke discussion to see how people felt. The "consistent with git-log and all that stuff" argument is quite persuasive to me, but it's a convenience feature, so it depends on how people feel.

Hint taken. Half of the patch is available at http://marc.info/?l=git&m=123207990016944

Is -t/--full-tree okay? I'd rather use -a/--all, but that's taken. -t isn't used by grep(1) either.

Sorry for veering off on an inappropriate tangent.

"George Spelvin" <linux@horizon.com> writes:

There is nothing that needs forgiveness. Discussion is a good thing, as long as it is not about useless bikeshedding (and I should just learn to ignore discussions that are useless, instead of getting upset. Lucikly we haven't had many).

If you suspected that the above may be true, that the new behaviour should be the default, and that many people may support that view, and wanted to confirm it, then your justification should have really spelled it out.

Consistency among tools with a similar objective is a good thing to aim for.

"log" especially "log -p" is about inspecting _changes_ and to understand the change you would more often than not want to view the change in the entire context (that is the point of having an atomic while-tree commit).

On the other hand, "grep" is about narrowing down the _state_ you would want to inspect, and unlike the case when you _inspect changes_ where you would more often want to have the entire context, you would more often want to omit unrelated parts of the tree while you are _narrowing down state_ to inspect. This is especially true when you run it from a subdirectory, and by definition when you are already in a subdirectory, your attention is already narrowed down to the part of the whole tree you are currently in.

So in that sense, I do not see a "similar objective" between what log and grep are used for. They may superficially look similar, but the useful mode of operation between them can be different because they are used for different purposes.

George Spelvin, 27.02.2009:

I use ctags from within the editor Vim therefor. Also grepping may show too many unwanted results.

Markus