Alexander Gavrilov writes: > File encoding can be specified in the following ways: > > 1) It defaults to the current locale encoding. > 2) It can be overridden by setting the gui.encoding option. I'm happy with providing a way to say what the default encoding of files in the repository is, but I wonder why it is seen as a property of the GUI. Is it just that there is an existing "gui" section that is convenient to use, or does git-gui already use gui.encoding (before this patch series), or is there some other reason? > 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? (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.) > Since git apparently cannot work with filenames in non-locale > encodings anyway, I did not try to do anything about it apart > from fixing some obvious bugs. For Linux, filenames are sequences of non-null bytes, so using binary encoding to read them in Tcl sounds about right. > There are also some bugs in handling of commit encodings in gitk, > but they are out of the scope of this series. I'm interested to hear what they are. 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
