sparse support in pu

sparse support in pu

[skillzero]

I had a couple comments and questions about the sparse stuff recently
merged into pu. First, I think it's an awesome feature. It's a nice
solution to my problems (1.5 GB tree where most people only need a
small subset, but with a lot of shared pieces).

1. Have people decided whether it should be on by default if you have
a .git/info/sparse file? I'd definitely like it to be on by default.
When I first tried it, I didn't realize I had to use --sparse to git
checkout to get it to use the sparse rules. The same goes for a merge
I did that happened to have a file in the excluded area (it included
it because I didn't use --sparse to git merge).

2. Is it not hooked up to git reset yet? I did a git checkout --sparse
and things look liked I expected then I did a git reset --hard
origin/master and it started checking out all the stuff previously
excluded via .git/info/sparse. I tried --sparse, but it didn't know
about that option.

3. One thing that was confusing is that I needed a trailing slash on
directories in .git/info/sparse to get them excluded. This seems
different than .gitignore, which works for me without the trailing
slash.

BTW...How to people normally try out stuff in pu? Do you just replace
your normal git stuff with the pu build? That's what I did because I
wasn't sure if I did /test/git if the other tools git invokes would
use the release version of git or the ones relative to itself (i.e.
the ones in /test/ for me). It seems like the only way to really test
stuff is to use it for your real work, but I also don't want to
corrupt our production repositories by using an experimental version
of git.

Re: sparse support in pu

[Nguyen Thai Ngoc Duy]

On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
> 1. Have people decided whether it should be on by default if you have
> a .git/info/sparse file? I'd definitely like it to be on by default.
> When I first tried it, I didn't realize I had to use --sparse to git
> checkout to get it to use the sparse rules. The same goes for a merge
> I did that happened to have a file in the excluded area (it included
> it because I didn't use --sparse to git merge).

I tend to make it enabled by default too. I have made it stricter to
trigger reading sparse in unpack_trees() -- only do it when
unpack_opts.update is TRUE. This should make it safer to be enabled by
default.

> 2. Is it not hooked up to git reset yet? I did a git checkout --sparse
> and things look liked I expected then I did a git reset --hard
> origin/master and it started checking out all the stuff previously
> excluded via .git/info/sparse. I tried --sparse, but it didn't know
> about that option.

Because sparse was disabled by default, and "git reset" did not enable
it. It'd be interesting to see what "git reset --hard" should do in
this case: will it apply .git/info/sparse or not, which brings us back
to the "default or not" question, hmm..

> 3. One thing that was confusing is that I needed a trailing slash on
> directories in .git/info/sparse to get them excluded. This seems
> different than .gitignore, which works for me without the trailing
> slash.

Hmm.. probably because Git feeds directories to .gitignore handling
functions. There is not much I can do, index does not have
directories. I don't know if it's worth generating "directories" from
index.
-- 
Duy

Re: sparse support in pu

[skillzero]

On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
> On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
>> 1. Have people decided whether it should be on by default if you have
>> a .git/info/sparse file? I'd definitely like it to be on by default.
>> When I first tried it, I didn't realize I had to use --sparse to git
>> checkout to get it to use the sparse rules. The same goes for a merge
>> I did that happened to have a file in the excluded area (it included
>> it because I didn't use --sparse to git merge).
>
> I tend to make it enabled by default too. I have made it stricter to
> trigger reading sparse in unpack_trees() -- only do it when
> unpack_opts.update is TRUE. This should make it safer to be enabled by
> default.

Other than it being new and not-widely-tested code, is there any
additional risk to having it enabled by default if there are no sparse
patterns defined?

It would be nice if .git/info/sparse is there by default (like
.git/info/exclude) with some commented out instructions (also like
.git/info/exclude).

>> 2. Is it not hooked up to git reset yet? I did a git checkout --sparse
>> and things look liked I expected then I did a git reset --hard
>> origin/master and it started checking out all the stuff previously
>> excluded via .git/info/sparse. I tried --sparse, but it didn't know
>> about that option.
>
> Because sparse was disabled by default, and "git reset" did not enable
> it. It'd be interesting to see what "git reset --hard" should do in
> this case: will it apply .git/info/sparse or not, which brings us back
> to the "default or not" question, hmm..

It seems like if it's going to be off by default (which it hopefully
won't be) then git reset would need to support --sparse since
otherwise, you'd never be able to git reset without undoing your
sparse options (unless you did a subsequent git checkout --sparse).

I also noticed that after I did the git reset, the sparse stuff seemed
to get into a weird state such that sparse patterns weren't working
reliably. For example, I couldn't get it to exclude a directory.

>> 3. One thing that was confusing is that I needed a trailing slash on
>> directories in .git/info/sparse to get them excluded. This seems
>> different than .gitignore, which works for me without the trailing
>> slash.
>
> Hmm.. probably because Git feeds directories to .gitignore handling
> functions. There is not much I can do, index does not have
> directories. I don't know if it's worth generating "directories" from
> index.

Maybe just add a note in the documentation? If there's a default
.git/info/sparse file then it might be good place to put a note as
well.

Re: sparse support in pu

[Johannes Schindelin]

Hi,

On Mon, 17 Aug 2009, skillzero@gmail.com wrote:

> On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
> > On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
> >> 1. Have people decided whether it should be on by default if you have 
> >>    a .git/info/sparse file? I'd definitely like it to be on by 
> >>    default.  When I first tried it, I didn't realize I had to use 
> >>    --sparse to git checkout to get it to use the sparse rules. The 
> >>    same goes for a merge I did that happened to have a file in the 
> >>    excluded area (it included it because I didn't use --sparse to git 
> >>    merge).
> >
> > I tend to make it enabled by default too. I have made it stricter to 
> > trigger reading sparse in unpack_trees() -- only do it when 
> > unpack_opts.update is TRUE. This should make it safer to be enabled by 
> > default.
> 
> Other than it being new and not-widely-tested code, is there any 
> additional risk to having it enabled by default if there are no sparse 
> patterns defined?

I think that in and of itself is reason enough to turn off the feature 
when .git/info/sparse is not present.

It also may have a runtime cost, dunno.

> It would be nice if .git/info/sparse is there by default (like
> .git/info/exclude) with some commented out instructions (also like
> .git/info/exclude).

I'm not a fan of this idea.

> >> 3. One thing that was confusing is that I needed a trailing slash on 
> >>    directories in .git/info/sparse to get them excluded. This seems 
> >>    different than .gitignore, which works for me without the trailing 
> >>    slash.
> >
> > Hmm.. probably because Git feeds directories to .gitignore handling 
> > functions. There is not much I can do, index does not have 
> > directories. I don't know if it's worth generating "directories" from 
> > index.
> 
> Maybe just add a note in the documentation? If there's a default 
> .git/info/sparse file then it might be good place to put a note as well.

I rather think that this should be fixed.  Maybe you can come up with a 
patch to the tests which shows this behavior (with test_expect_failure)?  
Then it will be much easier to come up with a fix.

Ciao,
Dscho

Re: sparse support in pu

[skillzero]

On Mon, Aug 17, 2009 at 2:15 AM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Aug 2009, skillzero@gmail.com wrote:
>
>> On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
>> > On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
>> >> 1. Have people decided whether it should be on by default if you have
>> >>    a .git/info/sparse file? I'd definitely like it to be on by
>> >>    default.  When I first tried it, I didn't realize I had to use
>> >>    --sparse to git checkout to get it to use the sparse rules. The
>> >>    same goes for a merge I did that happened to have a file in the
>> >>    excluded area (it included it because I didn't use --sparse to git
>> >>    merge).
>> >
>> > I tend to make it enabled by default too. I have made it stricter to
>> > trigger reading sparse in unpack_trees() -- only do it when
>> > unpack_opts.update is TRUE. This should make it safer to be enabled by
>> > default.
>>
>> Other than it being new and not-widely-tested code, is there any
>> additional risk to having it enabled by default if there are no sparse
>> patterns defined?
>
> I think that in and of itself is reason enough to turn off the feature
> when .git/info/sparse is not present.
>
> It also may have a runtime cost, dunno.

I was thinking that it would effectively do this:

Try to read .git/info/sparse
if valid patterns read
   Sparse is enabled
else (e.g. file missing or nothing but empty lines/comments)
   Sparse is disabled

I wouldn't think there would be any additional cost or risk (other
than the extra code to read the .git/info/sparse file) because the
result is the same as if sparse had been disabled by being defaulted
to off since even in the default off case, it's still a runtime check.

I would think --sparse would really only be useful as a way to negate
--no-sparse (i.e. act as if .git/info/sparse didn't exist
temporarily).

Re: sparse support in pu

[Johannes Sixt]

Johannes Schindelin schrieb:
> On Mon, 17 Aug 2009, skillzero@gmail.com wrote:
>> On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
>>> On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
>>>> 1. Have people decided whether it should be on by default if you have 
>>>>    a .git/info/sparse file? I'd definitely like it to be on by 
>>>>    default.  When I first tried it, I didn't realize I had to use 
>>>>    --sparse to git checkout to get it to use the sparse rules. The 
>>>>    same goes for a merge I did that happened to have a file in the 
>>>>    excluded area (it included it because I didn't use --sparse to git 
>>>>    merge).
>>> I tend to make it enabled by default too. I have made it stricter to 
>>> trigger reading sparse in unpack_trees() -- only do it when 
>>> unpack_opts.update is TRUE. This should make it safer to be enabled by 
>>> default.
>> Other than it being new and not-widely-tested code, is there any 
>> additional risk to having it enabled by default if there are no sparse 
>> patterns defined?
> 
> I think that in and of itself is reason enough to turn off the feature 
> when .git/info/sparse is not present.

I might have missed something: Would there be any observable difference
between whether .git/info/sparse is absent and whether it is empty? If
not, what do you mean by "turn the feature off"?

>> It would be nice if .git/info/sparse is there by default (like
>> .git/info/exclude) with some commented out instructions (also like
>> .git/info/exclude).
> 
> I'm not a fan of this idea.

For any particular reason?

-- Hannes

Re: sparse support in pu

[Johannes Schindelin]

Hi,

On Mon, 17 Aug 2009, Johannes Sixt wrote:

> Johannes Schindelin schrieb:
> > On Mon, 17 Aug 2009, skillzero@gmail.com wrote:
> >> On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
> >>> On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
> >>>> 1. Have people decided whether it should be on by default if you have 
> >>>>    a .git/info/sparse file? I'd definitely like it to be on by 
> >>>>    default.  When I first tried it, I didn't realize I had to use 
> >>>>    --sparse to git checkout to get it to use the sparse rules. The 
> >>>>    same goes for a merge I did that happened to have a file in the 
> >>>>    excluded area (it included it because I didn't use --sparse to git 
> >>>>    merge).
> >>> I tend to make it enabled by default too. I have made it stricter to 
> >>> trigger reading sparse in unpack_trees() -- only do it when 
> >>> unpack_opts.update is TRUE. This should make it safer to be enabled by 
> >>> default.
> >> Other than it being new and not-widely-tested code, is there any 
> >> additional risk to having it enabled by default if there are no sparse 
> >> patterns defined?
> > 
> > I think that in and of itself is reason enough to turn off the feature 
> > when .git/info/sparse is not present.
> 
> I might have missed something: Would there be any observable difference
> between whether .git/info/sparse is absent and whether it is empty?

There _should_ not be an _observable_ difference.

> If not, what do you mean by "turn the feature off"?

There is a global variable which triggers the code path that looks through 
the sparse patterns.  I'd like this variable to be "off" by default.

> >> It would be nice if .git/info/sparse is there by default (like 
> >> .git/info/exclude) with some commented out instructions (also like 
> >> .git/info/exclude).
> > 
> > I'm not a fan of this idea.
> 
> For any particular reason?

First, it is an experimental feature.  I'd hate it if people who do not 
want to use the sparse feature are affected.

Second, even if the sparse pattern list is empty, an additional call to 
the function that matches files against the pattern would take additional 
runtime.

If I had time, I could think of a third reason.

Ciao,
Dscho

Re: sparse support in pu

[Nguyen Thai Ngoc Duy]

[I haven't read the rest of the mail, will read it through later]

On Mon, Aug 17, 2009 at 3:49 PM, <skillzero@gmail.com> wrote:
> It would be nice if .git/info/sparse is there by default (like
> .git/info/exclude) with some commented out instructions (also like
> .git/info/exclude).

No it can't be there by default. An empty .git/info/sparse means clear
assume-unchanged bit out of all files in index. It's not the same as
lacking .git/info/sparse (which does disable sparse checkout feature).
-- 
Duy

Re: sparse support in pu

[Johannes Sixt]

Nguyen Thai Ngoc Duy schrieb:
> [I haven't read the rest of the mail, will read it through later]
> 
> On Mon, Aug 17, 2009 at 3:49 PM, <skillzero@gmail.com> wrote:
>> It would be nice if .git/info/sparse is there by default (like
>> .git/info/exclude) with some commented out instructions (also like
>> .git/info/exclude).
> 
> No it can't be there by default. An empty .git/info/sparse means clear
> assume-unchanged bit out of all files in index. It's not the same as
> lacking .git/info/sparse (which does disable sparse checkout feature).

Huh? Shouldn't the meaning of .git/info/sparse be: "the files mentioned in
this file are not checked out." That is, if the file is empty, then no
file is not checked out, IOW, all files are checked out.

In order to advocate my earlier proposal: Name the file
.git/info/phantoms, then it's clear: "The files mentioned here are
phantoms" - they exist in the index, but not in the worktree; no phantoms
means that everything is checked out.

-- Hannes

Re: sparse support in pu

[Nguyen Thai Ngoc Duy]

On Mon, Aug 17, 2009 at 5:36 PM, Johannes Sixt<j.sixt@viscovery.net> wrote:
> Nguyen Thai Ngoc Duy schrieb:
>> [I haven't read the rest of the mail, will read it through later]
>>
>> On Mon, Aug 17, 2009 at 3:49 PM, <skillzero@gmail.com> wrote:
>>> It would be nice if .git/info/sparse is there by default (like
>>> .git/info/exclude) with some commented out instructions (also like
>>> .git/info/exclude).
>>
>> No it can't be there by default. An empty .git/info/sparse means clear
>> assume-unchanged bit out of all files in index. It's not the same as
>> lacking .git/info/sparse (which does disable sparse checkout feature).
>
> Huh? Shouldn't the meaning of .git/info/sparse be: "the files mentioned in
> this file are not checked out." That is, if the file is empty, then no
> file is not checked out, IOW, all files are checked out.

That's correct. Empty .git/info/sparse -> no assume-unchanged files ->
all files are checked out. That's what I meant. It's different from
empty .git/info/sparse as "don't touch index and worktree, leave them
as they are no matther if they have assume-unchanged files".

> In order to advocate my earlier proposal: Name the file
> .git/info/phantoms, then it's clear: "The files mentioned here are
> phantoms" - they exist in the index, but not in the worktree; no phantoms
> means that everything is checked out.

OK. Phantom checkout, must be unique in VCS world ;-) If no one
objects my next series will use this name as it's better than "sparse"
and "assume-unchanged" is just too vague. Would option names to
enable/disable this be --with[out]-phantoms?
-- 
Duy

Re: sparse support in pu

[Nguyen Thai Ngoc Duy]

On Mon, Aug 17, 2009 at 4:15 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
>> >> 3. One thing that was confusing is that I needed a trailing slash on
>> >>    directories in .git/info/sparse to get them excluded. This seems
>> >>    different than .gitignore, which works for me without the trailing
>> >>    slash.
>> >
>> > Hmm.. probably because Git feeds directories to .gitignore handling
>> > functions. There is not much I can do, index does not have
>> > directories. I don't know if it's worth generating "directories" from
>> > index.
>>
>> Maybe just add a note in the documentation? If there's a default
>> .git/info/sparse file then it might be good place to put a note as well.
>
> I rather think that this should be fixed.  Maybe you can come up with a
> patch to the tests which shows this behavior (with test_expect_failure)?
> Then it will be much easier to come up with a fix.

Agreed. Thanks.
-- 
Duy

Re: sparse support in pu

[Johannes Sixt]

Nguyen Thai Ngoc Duy schrieb:
> On Mon, Aug 17, 2009 at 5:36 PM, Johannes Sixt<j.sixt@viscovery.net> wrote:
>> In order to advocate my earlier proposal: Name the file
>> .git/info/phantoms, then it's clear: "The files mentioned here are
>> phantoms" - they exist in the index, but not in the worktree; no phantoms
>> means that everything is checked out.
> 
> OK. Phantom checkout, must be unique in VCS world ;-) If no one
> objects my next series will use this name as it's better than "sparse"
> and "assume-unchanged" is just too vague. Would option names to
> enable/disable this be --with[out]-phantoms?

--phantoms vs. --no-phantoms?

-- Hannes

Re: sparse support in pu

[Nguyen Thai Ngoc Duy]

On Mon, Aug 17, 2009 at 7:00 PM, Johannes Sixt<j.sixt@viscovery.net> wrote:
> Nguyen Thai Ngoc Duy schrieb:
>> On Mon, Aug 17, 2009 at 5:36 PM, Johannes Sixt<j.sixt@viscovery.net> wrote:
>>> In order to advocate my earlier proposal: Name the file
>>> .git/info/phantoms, then it's clear: "The files mentioned here are
>>> phantoms" - they exist in the index, but not in the worktree; no phantoms
>>> means that everything is checked out.
>>
>> OK. Phantom checkout, must be unique in VCS world ;-) If no one
>> objects my next series will use this name as it's better than "sparse"
>> and "assume-unchanged" is just too vague. Would option names to
>> enable/disable this be --with[out]-phantoms?
>
> --phantoms vs. --no-phantoms?

Yeah good too. I have probably dealed with autotools too much lately.
-- 
Duy

Re: sparse support in pu

[Johannes Schindelin]

Hi,

On Mon, 17 Aug 2009, Nguyen Thai Ngoc Duy wrote:

> On Mon, Aug 17, 2009 at 5:36 PM, Johannes Sixt<j.sixt@viscovery.net> wrote:
>
> > In order to advocate my earlier proposal: Name the file 
> > .git/info/phantoms, then it's clear: "The files mentioned here are 
> > phantoms" - they exist in the index, but not in the worktree; no 
> > phantoms means that everything is checked out.
> 
> OK. Phantom checkout, must be unique in VCS world ;-) If no one objects 
> my next series will use this name as it's better than "sparse" and 
> "assume-unchanged" is just too vague. Would option names to 
> enable/disable this be --with[out]-phantoms?

The term 'phantom' is not specified at all.  At least interested people on 
the mailing list know 'sparse'.  But I agree that the naming is a major 
problem, hence my earlier (unanswered) call.

However, I would find specifying what you do _not_ want in that file 
rather unintuitive, in the same leage as receive.denyNonFastForwards = no.

If I want to have a sparse checkout, I know which files I _want_.

Ciao,
Dscho

Re: sparse support in pu

[Peter Harris]

On Mon, Aug 17, 2009 at 8:29 AM, Johannes Schindelin wrote:
> If I want to have a sparse checkout, I know which files I _want_.

That's funny. I have a git tree that would benefit from sparse
checkout. I know which path I _don't_ want. Specifying all the paths I
want would be a rather longer (and more error-prone) list. I suspect
it would be best to support both.

Does sparse use the same parser as .gitignore? (I guess not, if it
handles trailing slashes differently?) If so, it would be trivial to
turn "exclude path" into "exclude all but path" (or vice-versa) with:

*
!path

Peter Harris

Re: sparse support in pu

[Nguyen Thai Ngoc Duy]

On Mon, Aug 17, 2009 at 7:29 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Aug 2009, Nguyen Thai Ngoc Duy wrote:
>
>> On Mon, Aug 17, 2009 at 5:36 PM, Johannes Sixt<j.sixt@viscovery.net> wrote:
>>
>> > In order to advocate my earlier proposal: Name the file
>> > .git/info/phantoms, then it's clear: "The files mentioned here are
>> > phantoms" - they exist in the index, but not in the worktree; no
>> > phantoms means that everything is checked out.
>>
>> OK. Phantom checkout, must be unique in VCS world ;-) If no one objects
>> my next series will use this name as it's better than "sparse" and
>> "assume-unchanged" is just too vague. Would option names to
>> enable/disable this be --with[out]-phantoms?
>
> The term 'phantom' is not specified at all.  At least interested people on
> the mailing list know 'sparse'.  But I agree that the naming is a major
> problem, hence my earlier (unanswered) call.
>
> However, I would find specifying what you do _not_ want in that file
> rather unintuitive, in the same leage as receive.denyNonFastForwards = no.

But .gitignore is because I do _not_ want some files. Hey, how about
worktree-ignore? Turning it to positive matching instead of excluding
is not hard, but I have a feeling that people (OK, I) usually want to
ignore some directories. Applying trick:

*
!foo/
!bar/

to have foo and bar ignored too often would not be fun.
-- 
Duy

Re: sparse support in pu

[Johannes Schindelin]

Hi,

On Mon, 17 Aug 2009, Peter Harris wrote:

> On Mon, Aug 17, 2009 at 8:29 AM, Johannes Schindelin wrote:
> > If I want to have a sparse checkout, I know which files I _want_.
> 
> That's funny. I have a git tree that would benefit from sparse checkout. 
> I know which path I _don't_ want. Specifying all the paths I want would 
> be a rather longer (and more error-prone) list. I suspect it would be 
> best to support both.

Yes, I agree, but the common case is for people to know what they are 
working on, right?

> Does sparse use the same parser as .gitignore? (I guess not, if it
> handles trailing slashes differently?) If so, it would be trivial to
> turn "exclude path" into "exclude all but path" (or vice-versa) with:
> 
> *
> !path

That was the idea behind my suggestion to allow .gitignore syntax.  And 
indeed, that is what happened.

Ciao,
Dscho

Re: sparse support in pu

[Peter Harris]

On Mon, Aug 17, 2009 at 9:23 AM, Johannes Schindelin wrote:
> On Mon, 17 Aug 2009, Peter Harris wrote:
>> On Mon, Aug 17, 2009 at 8:29 AM, Johannes Schindelin wrote:
>> > If I want to have a sparse checkout, I know which files I _want_.
>>
>> That's funny. I have a git tree that would benefit from sparse checkout.
>> I know which path I _don't_ want. Specifying all the paths I want would
>> be a rather longer (and more error-prone) list. I suspect it would be
>> best to support both.
>
> Yes, I agree, but the common case is for people to know what they are
> working on, right?

I would presume so, but anecdotal "evidence" points the other way. I
don't have a statistically significant number of samples. Maybe it
should have been asked in the Git User's Survey? ;-)

>> Does sparse use the same parser as .gitignore? (I guess not, if it
>> handles trailing slashes differently?) If so, it would be trivial to
>> turn "exclude path" into "exclude all but path" (or vice-versa) with:
>>
>> *
>> !path
>
> That was the idea behind my suggestion to allow .gitignore syntax.  And
> indeed, that is what happened.

Excellent. In that case, I don't care which way around the default is.

Thanks,
 Peter Harris

Re: sparse support in pu

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> That's funny. I have a git tree that would benefit from sparse checkout. 
>> I know which path I _don't_ want. Specifying all the paths I want would 
>> be a rather longer (and more error-prone) list. I suspect it would be 
>> best to support both.
>
> Yes, I agree, but the common case is for people to know what they are 
> working on, right?

I either may be working on Documentation/ (I know I do not care about
everthing else so I can afford to list Makefile and Documentation/ in the
"interesting" list), or I either may be working on code (I do not know how
many code directories there are, and do not care to list them, but I know
I do not need Documentation/ and contrib/).  You need both ways.

And with .gitignore syntax you can have both.

Re: sparse support in pu

[James Pickens]

On Mon, Aug 17, 2009, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:
> The term 'phantom' is not specified at all.  At least interested people on
> the mailing list know 'sparse'.  But I agree that the naming is a major
> problem, hence my earlier (unanswered) call.

I don't particularly like 'phantom' either, but I haven't come up with any
good alternatives.  'sparse' seems fine to me, though it might make sense
to lengthen it to 'sparse-checkout'.

> However, I would find specifying what you do _not_ want in that file
> rather unintuitive, in the same leage as receive.denyNonFastForwards = no.
>
> If I want to have a sparse checkout, I know which files I _want_.

I agree; specifying which files you don't want seems backwards to me.

James

Re: sparse support in pu

[Johannes Schindelin]

Hi,

On Mon, 17 Aug 2009, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> That's funny. I have a git tree that would benefit from sparse checkout. 
> >> I know which path I _don't_ want. Specifying all the paths I want would 
> >> be a rather longer (and more error-prone) list. I suspect it would be 
> >> best to support both.
> >
> > Yes, I agree, but the common case is for people to know what they are 
> > working on, right?
> 
> I either may be working on Documentation/ (I know I do not care about 
> everthing else so I can afford to list Makefile and Documentation/ in 
> the "interesting" list), or I either may be working on code (I do not 
> know how many code directories there are, and do not care to list them, 
> but I know I do not need Documentation/ and contrib/).  You need both 
> ways.
> 
> And with .gitignore syntax you can have both.

I was fully aware of this.  It was the only reason I proposed the 
.gitignore syntax.

My point was that the direction should be dictated by convenience to those 
who need the feature most.

And maybe by asking yourself the question "what would I understand by 
'sparse files'?"

Ciao,
Dscho