On Sat, 20 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> On 9/20/08, Jakub Narebski <jnareb@xxxxxxxxx> 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
--
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
