On 9/17/08, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > >> You have decided then on the term 'narrow checkout', and not > >> 'partial checkout' or 'sparse checkout', then? > > > > Not yet. I tend to prefer partial/sparse checkout. Probably should > > have a look at how other SCMs do and what term they use. If Git's > > functionality is so different, a different term might notice people > > about that. > > > Perhaps whip up a survey? Just kidding (or not). Well I've been asking about the name on this list long enough. I'm going with 'sparse checkout' as svn' sparse directories does not look too different from git's. > >>> When you apply new narrow spec to your working directory using either > >>> --path, --add-path or --remove-path, it will update "checkout" status > >>> in index accordingly. Moreover, if a file is marked "no-checkout" and > >>> is present in working directory, it will be removed. If a file is > >>> turned from "no-checkout" to "checkout", then it will be added again > >>> to working directory. Modified and unmerged entries can't bear > >>> "no-checkout" status, if narrow spec applies to them, "git checkout" > >>> will refuse to update working directory. > >> > >> > >> Do I understand correctly, that if one uses --path=<colon separated list> > >> _only_ filenames matching one of patterns specified would be checked out, > >> --add-path=<path> would additionally checkout given path and mark "wanted", > >> and --remove-path=<path> would additionally mark "no-checkout" and remove > >> path? > > > > --add-path/--remove-path also use narrow spec, which could be more > > than one pattern. > > > What is the difference then between --add-path and --path? The fact > that --add-path can be incremental, and --path starts always from > an empty set? --path clears out all no-checkout bits and set again based on the given spec. --add-path adds more checkout entries based on the given spec, think of widening checkout area. --remove-path does narrow the checkout area. They are like '=', '+=' and '-=' operators respectively. > > >> What --add-path starts from, i.e. does > >> > >> $ git checkout --add-path=.gitignore > >> > >> starts from empty set if --add-path is first, or from full set as without > >> --add-path? > > > > I'm not sure I understand this. > > > Well, what I wanted to ask is if --remove-path starts from fully > checked out repository, for example if > > $ git checkout --remove-path=some_large_file > > would checkout all files _except_ 'some_large_file'. No, there is no negative spec. Like I said above, --remove-path is to remove some files based on the given spec. > > >> And is <pathspec> matched against full pathname, or like .gitignore > >> rules, i.e. as full pathname if it has at least one '/' in it? > > > > like shell wildcard, full pathname must match. On my way back home, I > > thought I should have removed mention of "pathspec", which behaves a > > little bit different. > > > > Also those specs are relative to working directory though, so if you > > are in b/c and want to match d, you only need to type --add-path=d > > instead of --add-path=b/c/d. Will add this to doc. > > > I would have thought that you follow the same rules (perhaps with > exception of !path excluding rule) like for gitignore and gitattributes. > Um.. never thought of gitignores/gitattributes rules before. It's a good idea all narrowspec/gitignore/gitattributes using the same rules. Thanks. -- Duy -- 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
