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-clonewas important, rather worry about people may misunderstand that it is"narrow clone" (do not fetch objects outside given paths for allhistory). Maybe "git clone --narrow-checkout" would be better."--reset-path", I think, is a better name though. It would express therelation compared to --add-path and --remove-path.
> > - 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 haveworked already for .gitignore, I dunno) and backslash escape forcolons.
> 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.
> > 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..-- Duy��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
