On Sun, Dec 03, 2017 at 07:48:01PM +0100, Lars Schneider wrote: > > - if core.convertEncoding is true, then for any file with an > > encoding=foo attribute, internally run iconv(foo, utf8) in > > convert_to_git(), and likewise iconv(utf8, foo) in > > convert_to_working_tree. > > > > - I'm not sure if core.convertEncoding should be enabled by default. If > > it's a noop as long as there's no encoding attribute, then it's > > probably fine. But I would not want accidental conversion or any > > slowdown for the common case that the user wants no conversion. > > I think we should mimic the behavior of "eol=crlf/lf" attribute. > > AFAIK whenever I set "*.ext text eol=crlf", then I can be sure the > file is checked out with CRLF independent of any of my local config > settings. Isn't that correct? I would expect a similar behavior if > "*.ext text encoding=utf16" is set. Wouldn't that mean that we do > not need a "core.convertEncoding" config?
Yeah, on further thought, that's probably the right thing. Both "eol" and "encoding" attributes are definite indications of what should happen (unlike "text", which is just saying you _could_ convert line endings if you wished to, and therefore has to be used in conjunction with a config setting). I like the name "encoding" for the attribute, but I do wonder if this would bite anybody using it already for other purposes (like gitk). > > There is one other approach, which is to really store utf-16 in the > > repository and better teach the diff tools to handle it (which are > > really the main thing in git that cares about looking into the blob > > contents). You can do this already with a textconv filter, but: > > > > 1. It's slow (though cacheable). > > > > 2. It doesn't work unless each repo configures the filter (so not on > > sites like GitHub, unless we define a micro-format that diff=utf16 > > should be textconv'd on display, and get all implementations to > > respect that). > > Actually, rendering diffs on Git hosting sites such as GitHub is one > of my goals. Therefore, storing content as UTF-16 wouldn't be a solution > for me. If there were a convention for specifying the attribute, I think sites like GitHub would start respecting it in the server-side diffs (though like I said, we could also just auto-detect via BOM without even requiring any attributes to be set up). > > 3. Textconv patches look good, but can't be applied. This occasionally > > makes things awkward, depending on your workflow. > > TBH I dont't understand what you mean here. What do you mean with > "textconv patches"? I mean the patch produced by "git diff" when textconv is in effect. That patch cannot be applied to the original content. E.g.: git init echo "* diff=foo" >.git/info/attributes git config diff.foo.textconv "sed s/^/foo:/" echo base >file git add file git commit -m base echo change >file git diff >patch git reset --hard git apply patch That works in the absence of the textconv, but not with it. (For a real binary file, you'd probably need "diff --binary" to produce a usable patch, but the principle is the same). -Peff
