Paul Mackerras schrieb: > Alexander Gavrilov writes: >> 3) It can be further set on per-file basis by specifying >> the 'encoding' attribute in gitattributes. > > I haven't used .gitattributes before, but I would expect that the > .gitattributes files would be stored in the repository along with > everything else. If that's the case, then for gitk at least there is > the question of which version of a given .gitattributes file one > should use when viewing the tree for a commit which isn't the > currently checked-out commit - do you use the version from that tree, > or the version in the working directory? We seem to be using the > latter at present, and caching the results. Is there a philosophical > reason to do that, other than speed? I understand your concerns that an encoding may be picked from the "wrong" .gitattributes file. But in practice it doesn't matter much, and picking the attribute from a past commit's tree would even be counter-productive: I'm about to add a .gitattributes file that specifies the encoding for some of my files *today* because I was not clever enough to anticipate the usefulness of an "encoding" attribute a year ago when those files were added to the repository. When I browse history, I *do* want that *today's* encoding is picked. > (Also it seems that we won't > notice if the user changes .gitattributes after we've looked at it, or > if they create one after we've looked for one and not found it.) This is not a show stopper, IMHO. The user will notice soon enough, and can restart gitk. Nobody sane will change the encoding attributes every hour. That said, a menu command to flush the attribute cache would be useful every now and then. -- Hannes -- 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
