git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org
Subject: Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
Date: Thu, 11 Dec 2008 17:41:03 -0800	[thread overview]
Message-ID: <7vy6ym9nm8.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LNX.1.00.0812111520490.19665@iabervon.org> (Daniel Barkalow's message of "Thu, 11 Dec 2008 15:30:45 -0500 (EST)")

Daniel Barkalow <barkalow@iabervon.org> writes:

>> That's the point. CE_VALID does not define checkout area while
>> CE_NO_CHECKOUT does.  If an entry is CE_VALID, it is still in checkout
>> area. But if it is CE_NO_CHECKOUT, "git grep" should ignore that path.
>> core.defaultsparse has nothing to do here.
>
> My point is that the index cannot tell git grep whether it should search a 
> path if the path isn't in the index.

Let's step back a bit.  I think "git grep" that stays silent outside of
the checkout area when used to grep in the work tree or in the index is a
mistake.

The problem "sparse checkout" attempts to address is not this:

    I ran "git init && git add ." in /usr/src by mistake.  There is no
    reason for coreutils that is in /usr/src/coreutils and gnucash that is
    in /usr/src/gnucash to share the same development history nor their
    should be any ordering between commits in these two independent
    projects.  I should have done N separate "init & add" independently at
    one level deeper in the directory hierarchy, but I am too lazy to
    filter branch the resulting mess now.

At least, it should not be that, at least to me.

"Sparse" is "I am not going to modify the files in these areas, and I know
they do not need to be present for my purposes (e.g. build), so I do not
need copies in the work tree."  It still works on the whole tree structure
recorded in the commit, but gives you a way to work inside a sparsely
populated work tree, iow, without checking everything out.

So "git grep -e frotz Documentation/", whether you only check out
Documentation or the whole tree, should grep only in Documentation area,
and "git grep -e frotz" should grep in the whole tree, even if you happen
to have a sparse checkout.  By definition, a sparse checkout has no
modifications outside the checkout area, so whenever grep wants to look
for strings outside the checkout area it should pretend as if the same
content as what the index records is in the work tree.  This is consistent
with the way how "git diff" in a sparsely checked out work tree should
behave.

If you understand that, it is clear what "git grep -e frotz HEAD^" should
do.  No checkout area is involved.

  reply	other threads:[~2008-12-12  1:42 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-27  0:28 What's cooking in git.git (Nov 2008, #06; Wed, 26) Junio C Hamano
2008-11-27 22:49 ` Johannes Schindelin
2008-11-28  2:06   ` Junio C Hamano
2008-11-28 11:47     ` Johannes Schindelin
2008-11-28 19:20       ` Shawn O. Pearce
2008-11-29  0:13         ` Junio C Hamano
2008-11-29  0:15           ` [PATCH] git add --intent-to-add: fix removal of cached emptiness Junio C Hamano
2008-11-29  3:51             ` [PATCH 1/3] builtin-rm.c: explain and clarify the "local change" logic Junio C Hamano
2008-11-29  3:55               ` [PATCH 2/3] git add --intent-to-add: fix removal of cached emptiness Junio C Hamano
2008-11-29 15:38                 ` Sverre Rabbelier
2008-11-30 19:21                   ` Jeff King
2008-11-29  3:56               ` [PATCH 3/3] git add --intent-to-add: do not let an empty blob committed by accident Junio C Hamano
2008-11-30 19:14                 ` Jeff King
2008-12-01  9:24                   ` Junio C Hamano
2008-11-29  1:25           ` What's cooking in git.git (Nov 2008, #06; Wed, 26) Daniel Barkalow
2008-11-29 13:02             ` Nguyen Thai Ngoc Duy
2008-11-30 10:29               ` Nguyen Thai Ngoc Duy
2008-11-30 21:26                 ` Daniel Barkalow
2008-12-06 17:26                   ` Nguyen Thai Ngoc Duy
2008-12-06 18:39                     ` Daniel Barkalow
2008-12-07 12:27                       ` Nguyen Thai Ngoc Duy
2008-12-07 21:26                         ` Daniel Barkalow
2008-12-08 12:51                           ` Nguyen Thai Ngoc Duy
2008-12-08 19:41                             ` Daniel Barkalow
2008-12-11 13:04                               ` Nguyen Thai Ngoc Duy
2008-12-11 20:30                                 ` Daniel Barkalow
2008-12-12  1:41                                   ` Junio C Hamano [this message]
2008-12-12  2:40                                     ` Daniel Barkalow
2008-12-12  3:12                                       ` Junio C Hamano
2008-12-12  3:36                                         ` Jeff King
2008-12-12 16:13                                     ` Nguyen Thai Ngoc Duy
2008-12-12 16:45                                       ` Johannes Sixt
2008-12-12 16:54                                         ` Nguyen Thai Ngoc Duy
2008-12-13  5:51                                           ` Junio C Hamano
2008-12-13  5:51                                       ` Junio C Hamano
2008-12-12 16:08                                   ` Nguyen Thai Ngoc Duy
2008-12-07  3:45                   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vy6ym9nm8.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).