Am 2012-07-31 22:39, schrieb Linus Torvalds:
On Tue, Jul 31, 2012 at 1:16 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
Eek.
Oh, I agree. Doing a full character set conversion both ways is quite
a bit more work.
Not just write_entry() codepath that creates the final paths on the
filesystem, you would need to touch lstat() calls that check the
existence and freshness of the path, once you go that route. I am
sure such a change can be made to work, but I am not sure how much
we would gain from one.
I think it might be interesting. I doubt it matters all that much any
more in Western Europe (Unicode really does seem to have largely taken
over), but I think Japan still uses Shift-JIS a lot.
Although maybe that is starting to fade too.
And it really is just a generalization of the OS X filesystem damage.
Linus
Hi,
(I'm on vacation myself, so I migth apologize for answering very late.)
I had done a fully fledges conversion back-and-force of file names.
Having e.g. ISO-8859-1 on disk and UTF-8 in the repo.
The basic idea came from Linus, and it needs conversion for
open() fopen(), unlink(), readdir(), stat(), lstat(), rename()
(and may be one or two more, I even added support in readlink()).
After doing the whole thing ready, I realized that UTF-8 became more and
more standard.
At the same time people started to enhance msysgit to use UTF-8 as well.
(Thanks to the contributors)
My feeling was that the "market window" for such a generic file name
conversion might be closed.
So, is there still a need for such a feature in git?
I wouldn't mind to re-base my pathch to master and post it within a
couple of days/weeks.
Thanks for git and all enhancements.
/Torsten
--
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