threads / discuss / 20623

sparse support in pu

Subject: sparse support in pu

## tl;dr

21 messages between Aug 17, 2009 and Aug 17, 2009.

replies: 20people: 7as markdown or json

skillzero@gmail.com· Aug 17, 2009, 06:09 UTC · lore

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.

Nguyen Thai Ngoc Duy· Aug 17, 2009, 08:17 UTC · re: skillzero@gmail.com · lore

Re: sparse support in pu

On Mon, Aug 17, 2009 at 1:09 PM, <skillzero@gmail.com> wrote:
Show 6 quoted lines
> 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.

Show 5 quoted lines
> 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
skillzero@gmail.com· Aug 17, 2009, 08:49 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: sparse support in pu

On Mon, Aug 17, 2009 at 1:17 AM, Nguyen Thai Ngoc Duy<pclouds@gmail.com> wrote:
Show 12 quoted lines
> 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).

Show 10 quoted lines
>> 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.

Show 9 quoted lines
>> 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.

Johannes Schindelin· Aug 17, 2009, 09:15 UTC · re: skillzero@gmail.com · lore

Re: sparse support in pu

Hi,
On Mon, 17 Aug 2009, skillzero@gmail.com wrote:
Show 18 quoted lines
> 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.
Show 12 quoted lines
> >> 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

skillzero@gmail.com· Aug 17, 2009, 09:41 UTC · re: Johannes Schindelin · lore

Re: sparse support in pu

On Mon, Aug 17, 2009 at 2:15 AM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:

Show 27 quoted lines
> 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).

Johannes Sixt· Aug 17, 2009, 09:51 UTC · re: Johannes Schindelin · lore

Re: sparse support in pu

Johannes Schindelin schrieb:
Show 20 quoted lines
> 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"?

Show 5 quoted lines
>> 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
Johannes Schindelin· Aug 17, 2009, 09:57 UTC · re: Johannes Sixt · lore

Re: sparse support in pu

Hi,
On Mon, 17 Aug 2009, Johannes Sixt wrote:
Show 24 quoted lines
> 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.

Show 7 quoted lines
> >> 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

Nguyen Thai Ngoc Duy· Aug 17, 2009, 11:43 UTC · re: Johannes Schindelin · lore

Re: sparse support in pu

On Mon, Aug 17, 2009 at 4:15 PM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:

Show 16 quoted lines
>> >> 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
Nguyen Thai Ngoc Duy· Aug 17, 2009, 10:21 UTC · re: skillzero@gmail.com · lore

Re: sparse support in pu

[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
Johannes Sixt· Aug 17, 2009, 10:36 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: sparse support in pu

Nguyen Thai Ngoc Duy schrieb:
Show 10 quoted lines
> [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
Nguyen Thai Ngoc Duy· Aug 17, 2009, 11:41 UTC · re: Johannes Sixt · lore

Re: sparse support in pu

On Mon, Aug 17, 2009 at 5:36 PM, Johannes Sixt<j.sixt@viscovery.net> wrote:
Show 15 quoted lines
> 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
Johannes Sixt· Aug 17, 2009, 12:00 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: sparse support in pu

Nguyen Thai Ngoc Duy schrieb:
Show 10 quoted lines
> 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
Nguyen Thai Ngoc Duy· Aug 17, 2009, 12:19 UTC · re: Johannes Sixt · lore

Re: sparse support in pu

On Mon, Aug 17, 2009 at 7:00 PM, Johannes Sixt<j.sixt@viscovery.net> wrote:
Show 13 quoted lines
> 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
Johannes Schindelin· Aug 17, 2009, 12:29 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: sparse support in pu

Hi,
On Mon, 17 Aug 2009, Nguyen Thai Ngoc Duy wrote:
Show 11 quoted lines
> 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

Peter Harris· Aug 17, 2009, 12:52 UTC · re: Johannes Schindelin · lore

Re: sparse support in pu

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
Johannes Schindelin· Aug 17, 2009, 13:23 UTC · re: Peter Harris · lore

Re: sparse support in pu

Hi,
On Mon, 17 Aug 2009, Peter Harris wrote:
Show 7 quoted lines
> 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?

Show 6 quoted lines
> 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

Peter Harris· Aug 17, 2009, 14:30 UTC · re: Johannes Schindelin · lore

Re: sparse support in pu

On Mon, Aug 17, 2009 at 9:23 AM, Johannes Schindelin wrote:
Show 11 quoted lines
> 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? ;-)

Show 9 quoted lines
>> 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
Junio C Hamano· Aug 17, 2009, 16:05 UTC · re: Johannes Schindelin · lore

Re: sparse support in pu

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 7 quoted lines
>> 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.
Johannes Schindelin· Aug 17, 2009, 17:13 UTC · re: Junio C Hamano · lore

Re: sparse support in pu

Hi,
On Mon, 17 Aug 2009, Junio C Hamano wrote:
Show 18 quoted lines
> 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

Nguyen Thai Ngoc Duy· Aug 17, 2009, 12:53 UTC · re: Johannes Schindelin · lore

Re: sparse support in pu

On Mon, Aug 17, 2009 at 7:29 PM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:

Show 22 quoted lines
> 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
James Pickens· Aug 17, 2009, 16:49 UTC · re: Johannes Schindelin · lore

Re: sparse support in pu

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

← back to recent threads