david@xxxxxxx wrote: > On Sun, 21 Oct 2007, Steffen Prohaska wrote: > >If a .gitattributes is in the work tree and we checkout a > >different head, the .gitattributes of the head we are switching > >to must have precedence. > > > >Maybe the gitattributes of a file should be part of the per-file > >flags in the index. Thus we could verify if the flags changed and > >if so, adjust the work tree accordig to the new flags. I'm > >lacking a deeper insight into the git internals. Therefore, I > >can't really say if the index is the right place. But it looks > >to me as if changing an attribute should be treated similar to a > >changing sha1, as far as the work tree is concerned. > > the problem with this is that each attribute ends up needing it's own > flag, which severely limits extending things (see the discussions on file > permissions for examples). it's also much harder to manipulate them then > in a file. Yea, you really don't want to copy .gitattributes into the per-file records in the index. That's not going to scale as more types of attributes are defined. Fortunately the .gitattributes file format was designed to be readable even when there's merge conflicts; that is it is a very simple line-oriented record format. One could difference the old .gitattributes currently found in the index against the .gitattributes we are switching to (from the target tree-ish), scan the lines removed/added, find which files those match against in the target tree-ish, and just add those files to the list of things we need to checkout. If any of those files is dirty then we just refuse the checkout, just as if the file was modified and we were switching branches. The user then needs to decide how to continue (probably stash the file and then restart the checkout). Rather simple IMHO. Of course I haven't gone into that part of read-tree recently, and the .gitattribute parser reads from the working directory, so you need to make sure you checkout the target .gitattributes file before anything else in the "to process list". -- Shawn. - 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
