Am 2012-07-31 22:39, schrieb Linus Torvalds:
On Tue, Jul 31, 2012 at 1:16 PM, Junio C Hamano <gits...@pobox.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to