On Thu, Oct 2, 2008 at 6:39 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On 10/01/2008 "Santi Béjar" <santi@xxxxxxxxxxx> wrote:
>>On Wed, Oct 1, 2008 at 2:09 PM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote:
>> > On 10/1/08, Santi Béjar <santi@xxxxxxxxxxx> wrote:
>> >> On Wed, Oct 1, 2008 at 12:20 PM, Santi Béjar <santi@xxxxxxxxxxx> wrote:
>> >> > Not in this half but I've seen that you added a --default-sparse flag
>> >> > to "git clone". I think it is useless as mostly always the one given
>> >> > in -sparse-checkout should be used.
>> >>
>> >>
>> >> To be more precise, whenever you do "git clone --sparse-checkout" you
>> >> will want it to be the default sparse pattern.
>> >
>> > Yes, if only the default pattern gets updated properly when you update
>> > your checkout area.
>>
>> I don't parse this sentence, but I cannot see the connection between
>> the default sparse pattern for _clone_ and updating it or the working
>> area.
>
> After clone with sparse "Documentation/" you may want to extend the checkout area to "t/" also. "git pull" after that should allow new files in Documentation/ as well as t/. So the default sparse pattern should be updated to "Documentation/:t/"
Sure.
[...]
>> > The hard part is how to update default pattern with
>> > --include-sparse and --exclude-sparse.
>>
>> Maybe you could let the core.defaultsparse be defined multiple times.
>>
>> [core]
>> defaultsparse = Documentation/*
>> defaultsparse = t/*
>> defaultsparse = !t/*svn*
>>
>> equivalent to
>>
>> [core]
>> defaultsparse = Documentation/*:t/*:!t/*svn*
>>
>> but it moves the complexity to the parsing of the config.
>
> There are two issues regarding --{in,ex}clude-sparse:
> 1. we need to save the prefix somehow. "git checkout --include-sparse='*.c'" in compat/ and the same command at top-level workdir give different result.
then, core.defaultsparse="compat//*.c" and core.defaultsparse="*.c", isn't it?
> If we don't save prefix, we get wrong result with defaultsparse. This one is easy although it may make sparse patterns and .git{ignore,attributes} look different.
Possible bug, currently in your sparse-checkout branch the prefix is not saved:
$ cd git
$ cd Documentation
$ git checkout --sparse=RelNotes*
$ git config -l | grep sparse
core.defaultsparse=RelNotes-1.*
> 2. cruft gets accumulated in core.defaultsparse. Consider this (assume we cloned with sparse "Documentation/")
>
> for i in 1 2 3;do
> git checkout --include-sparse="t/"
> git checkout --exclude-sparse="t/" # oops, I did not mean to do that
> done
>
> The default sparse pattern would be "Documentation/:t/:!t/:t/:!t/:t/:!t/" while it should be just "Documentation/". Another example is
>
> git checkout --include-sparse=t/test-lib.sh
> git checkout --include-sparse=t/
>
> The defaultsparse would be "Documentation/:t/test-lib.sh:t/" while a better defaultsparse should be "Documentation/:t/"
>
But these are the steps to reproduce what the user asked for, so I
don't see a problem.
> But maybe I just overlook this. Maybe just show the defaultsparse to people and let them clean it with "--reset-sparse".
Sure.
>
>> > Also, people can use "git
>> > update-index" to update checkout area, which should not touch default
>> > pattern at all.
>>
>> I would prefer having a --not-update-sparse-pattern.
>
> "git update-index" does not understand "sparse patterns" at all. It operates at file level. But it is plumbling anyway so those who use it should take care of default sparse pattern themselves.
Well, "git checkout <paths>" does the trick.
Santi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
