On Sun, Sep 21, 2008 at 12:11 PM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > On 9/21/08, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> "Nguyen Thai Ngoc Duy" <pclouds@xxxxxxxxx> writes: >> >> > On 9/21/08, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> >> > ... >> >> >> >> 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? >> > >> > No. .gitignore is tied to read_directory() while .gitattributes has >> > attributes attached. So I rolled out another one for index. >> >> >> I am sorry, but that sounds like a rather lame excuse. It certainly is >> possible to introduce an "ignored" attribute and have .gitattributes file >> specify that, instead of having an entry in .gitignore file, if you teach >> read_directory() to pay attention to the attributes mechanism. If we had >> from day one that a more generic gitattributes mechanism, I would imagine >> we wouldn't even had a separate .gitignore codepath but used the attribute >> mechanism throughout the system. >> >> Now I do not think we are ever going to deprecate gitignore and move >> everybody to "ignored" attributes, because such a transition would not buy >> the end users anything, but it technically is possible and would have been >> the right thing to do, if we were building the system from scratch. We >> still could add it as an optional feature (i.e. if a path has the >> attribute that says "ignored" or "not ignored", then that determines the >> fate of the path, otherwise we look at gitignore). >> >> I wouldn't be surprised if an alternative implementation of your code to >> assign "sparseness" to each path internally used "to-be-checked-out" >> attribute, and used that attribute to control how ls-files filters its >> output. >> >> A better excuse might have been that "I am not reading these patterns from >> anywhere but command line", but that got me thinking further. > > That "from command line" piece makes a bit of difference. For example > patterns separated by colons and backslash escape, but that does not > stop it from reusing attr.c. > >> How would that --narrow-match that is not stored anywhere on the >> filesystem but used only for filtering the output be any more useful than >> a grep that filters ls-files output in practice? > > Well, it works exactly like 'grep' internally. > >> I would imagine it would be much more useful if .git/info/attributes can >> specify "checkout" attribute that is defined like this: >> >> `checkout` >> ^^^^^^^^^^ >> >> This attribute controls if the path can be left not checked-out to the >> working tree. >> >> Unset:: >> Unsetting the `checkout` marks the path not to be checked out. >> >> Unspecified:: >> A path which does not have any `checkout` attribute specified is >> handled in no special way. >> >> Any value set to `checkout` is ignored, and git acts as if the >> attribute is left unspecified. >> >> Then whenever a new path enters the index, you _could_ check with the >> attribute mechanism to set the CE_NOCHECKOUT flag. Just like an already >> tracked path is not ignored even if it matches .gitignore pattern, a path >> without CE_NOCHECKOUT that is in the index is checked out even if it has >> checkout attribute Unset. >> >> Hmm? > > Well I think people would want to save no-checkout rules eventually. > But I don't know how they want to use it. Will the saved rules be hard > restriction, that no files can be checked out outside defined areas? > Will it be to save a couple of keystrokes, that is, instead of > typing "--reset-sparse=blah" all the time, now just "--reset-sparse" > and default rules will be applied? Your suggestion would be the third, > applying on new files only. > > Anyway I will try to extend attr.c a bit to take input from command > line, then move "sparse patterns" over to use attr.c. While I agree that the checkout attr looks like an attribute (so reusing attr.c is a good idea) and $GIT_DIR/info/gitattributes seems a good place to specify them, I think it will be better in the config $GIT_DIR/config. There it is clear that it is a local thing and you have "git config" to read and write them. Additionally you could have different patterns in the config (sparse.default, sparse.doc, sparse.src,...), although maybe it is not very useful. I think the main UI to sparse checkout should be a default sparse pattern that is used for "all" commands, like merge, reset, and checkout. Now it is too easy to escape from the sparse checkout, when you merge or checkout a branch with new files, when doing a "git reset --hard" (when you abort a failed merge), or when doing a diff (specially when you pull). 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
