Johannes Sixt writes: > 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. Fair enough. > > (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. The scenario I'm thinking of is this: a user clicks on a file to display it, sees that it isn't displayed using the encoding he wants, says "duh" and creates a .gitattributes file. User clicks on the file again, sees that it *still* isn't displayed using the right encoding, and says something worse than "duh". :) If it was just one .gitattributes file, then it wouldn't be hard to stat it each time we go to display some file, and throw away our cache if it has changed. But it looks like we would have to do N+1 stats for a file N levels deep in the tree (since it looks like we also need to stat $GIT_DIR/info/attributes). Still, it may be worth it. At least on Linux, stat is pretty fast. Paul. -- 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
