Re: [PATCH v2 00/14] Sparse checkout

[Jakub Narebski <jnareb@gmail.com>]

On Sat, 20 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> On 9/20/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>>  - "git clone --path" => "git clone --narrow-path"
>>>  - "git checkout --path" => "git checkout --reset-path"
>>
>>
>> I am not sure about that change, especially the fact that git-clone
>> and git-checkout use differently named options, because those options
>> affect clone only as they affect the checkout part of the clone.  One
>> would think that git-clone = git-init + git-remote add + git-fetch +
>> git-checkout, and that git-clone would simply pass sparse checkout
>> flags to git-checkout.
>>
> 
> Johannes sixt said --path was too generic so I changed the name. Hmm..
> I did not think the same option name for git-checkout and git-clone
> was important, rather worry about people may misunderstand that it is
> "narrow clone" (do not fetch objects outside given paths for all
> history). Maybe "git clone --narrow-checkout" would be better.

True, I didn't thought that git-clone can have option with explicit
'checkout' in a name, for example --checkout-paths, or --checkout-only,
or --narrow-checkout (although for me this one doesn't look as it
accepts arguments, at least on first glance), or --sparse-checkout
(the same).

> "--reset-path", I think, is a better name though. It would express the
> relation compared to --add-path and --remove-path.

I don't like very much '--reset-path' option name, because it is not
about 'reset' or 'resetting', but about limiting checkout to specified
paths.  Unfortunately --include / --exclude looks like are for ignoring
files, not marking files with "no-checkout" bit etc.

But I am not native English speaker.

Further proposals: --only ("git checkout --only <pattern>") with
--checkout-only as counterpart in git-clone; --limit-to, --sparse.


GNU tar uses --exclude and --exclude-file (with --no-recurse,
--no-wildcards, --no-wildcards-match-slash). wget uses --accept
and --reject for filename patterns, and --include / --exclude for
directories.  Neither looks right for sparse checkout in Git.

>>>  - New narrow spec (or "sparse patterns" from now) resembles
>>>    .gitignore patterns
>>
>>
>> You mean here that rules for patterns to select which parts of tree
>>  mark as "no-checkout" and/or checkout/leave in checkout are the same
>>  (or nearly the same) as rules for ignoring files, isn't it?
> 
> Yes, almost the same, exceptions include "./" support (this may have
> worked already for .gitignore, I dunno) and backslash escape for
> colons.

'./', or rather '/' support works for gitignore: this is the only way
to have pattern which matches only files in given directory, 
nonrecursively.  For example last line in last example on gitignore(5)
man page.

>>  BTW I think that the same rules are used in gitattributes, aren't
>>  they?
> 
> They have different implementations. Though the rules may be the same.

Were you able to reuse either one?

>>> Nguyễn Thái NgỠc Duy (14):
>>
>>  Errr... what happened here? For me it doesn't look like correct UTF-8
>>  encoding, but perhaps that it is just my news client (Gnus)...
> 
> The cover letter lacks MIME-Version and Content-Type, hmm..

Bug in git-format-patch? IIRC --cover-letter was added quite late, and
is quite a new option; some bugs might have been not ironed out yet.

-- 
Jakub Narebski
Poland