Особенности настройки git под windows

[@ipetropolsky]

Большое спасибо.

[@slavaz]

Хорошая статейка.

[@ivlis]

А почему нельзя редактировать сразу в utf8?

[@smind]

можно, отчего-ж нельзя, np++ или тот же far 2.х, но будут проблемы тогда при отображении списка новых/отредактированных файлов внутри коммита. Но в принципе не проблема…

[@slavaz]

Если не сложно, то распиши и этот путь джедая. Чтобы был выбор у народа :)

[@ivlis]

Если едитить в cp1251, то у народа с другими локалями будут траблы.

[@smind]

вы меня засомневали прям :), нет все ОК, проверил сейчас на машине с ru_RU.UTF-8
проблем нет, т.к. внутри оно все в utf-8 хранится.

[@smind]

т.е. commitencoding только указывает в какой кодировки идет входящий текст коммита, а сам коммит внутри базы хранится в utf-8 и клиенту отдается в той кодировке в которой он просит согласно logoutputencoding.

[@betalb]

Не совсем так
i18n.commitencoding действительно указывает в какой кодировке был введён комментарий, но текст комментария вносится в объект коммита без изменений, а в заголовок объекта пишется кодировка комментария.
Я не уверен только влияет-ли как-то этот заголовок на имя коммитера и автора.

Так что в какой кодировке вводится комментарий — абсолютно всё равно, главное что-бы Git знал какая это кодировка. Git log и некоторые другие комманды используют этот заголовок что-бы во время вывода на экран производить перекодирование в нужную кодировку (в UTF-8 или в ту, которая указана в i18n.logoutputencoding). Но только для форматов oneline, short, medium, full, fuller. Если задать формат явно, например --format=%s, то первая строка комментария будет выведена без изменений.

А вот с именами файлов беда. Если коротко — то лучше не пользоваться русскими именами файлов если с репозиторием будут работать под разными операционными системами.

[@Gorthauer87]

>commitencoding = cp1251
А потом на вас будут матерится пользователи *nix систем
Лучше попробуйте
code.google.com/p/tortoisegit/
плюс нормальный редактор с поддержкой юникода, можно и far, насколько я помню у него нету беды с юникодом, можно и notepad++, я же вообще windows портом KDEшного kate пользуюсь

[@smind]

см. выше

[@Gorthauer87]

Теперь спокоен :)

[@smind]

в совершенно правы tortoisegit хороший, нужный проект, просто мне удобны консольные утилиты, они есть в составе msysgit, и я написал как обойти некоторые проблемы работы git с консолью windows.

[@pipboy]

chcp 65001 и cmd.exe уже в utf-8

[@smind]

а имена русских файлов выглядят примерно так €€€€€€€€€€€€2009.xls…

[@smind]

в far-е (извиняюсь пропустил)

[@smind]

наврал… надо было после смены шрифта выйти из far и снова его запустить…

[@smind]

и да, к сожалению проблемы установка кодовой страницы utf-8 не решает… в отличии от описанного в топике.

[@xvoland]

Ай спасибо =)
Русских имён файлов пока не было, но знаю, что уже всё хорошо, спасибо!

[@Goodkat]

Сперва вы учите git понимать utf8, затем вы вдруг отказываетесь от utf8 в пользу старинной cp1251, а в конце вдруг выбираете кодировочку ещё древней — cp866 :)

Не лучше ли будет оставить всё в utf8, чтобы везде было одинаково?

[@smind]

для виндовой консоли родная кодовая страница это 866, от того и все эти ухищрения, не более… под линуксом у меня везде ru_RU.UTF-8, там все эти лишние мероприятия вообще не нужны… так же не нужны они если вы собираетесь пользоваться графической оболочкой для git.

[@Goodkat]

спасибо
действительно, в консоли команда
echo ыыы > ёёё.ййй
создаёт файл «ёёё.ййй», но записывает в него вопросики :(
это как-нибудь лечится?

[@wwarlock]

Да. Не сочтите за рекламу, но попробуйте вот это.
Правда здесь (http://wwarlock.blogspot.com/2009/06/utf-8-cygwin-17.html) для CygWin.

[@Goodkat]

спасибо!

[@Arvur]

Параметр quotepath = false мне не помог.
Команда git status выводит все, что угодно — вопросики, квадратики — но не русское имя.
Пробовал: играться с chcp, переключаться между cmd, far2 и bash. Не помогло.

Есть предположение, где грабли?

P.S. ОС Windows 7 Russian, версия msysgit: 1.7.4-preview20110204

[@Terentich]

У меня тоже самое. Решение пока не нашел.
Может кто-нибудь поможет нам?

[@dimmaq]

Как вариант — забить на тупую консоль Windows и пользоваться gui клиентом. Лично я перешел на tortoisegit.

[@Terentich]

К сожалению, для проектом под Windows часто приходится делать различные действия в FAR-е (Total commander и другие).

Если найду решение, напишу.

[@kachkaev]

После долгих мучений получилось решить проблему скачиванием utf8-версии mysysgit.

Сайт на японском, но ссылку на экзешник найти нетрудно.
http://tmurakam.org/git/

[@DenisO]

Только он не официальный, и экзешник с левого сайта. Грустный вариант.

[@xRemaLx]

Для использования git submodule еще небольшие настройки нужно добавить:
git config --global core.attributesfile "~/.gitattributes"
И в сам .gitattributes добавить запись:
.gitmodules eol=lf

[@Psixozzz]

Для тех, кто выйдет на эту заметку как и я, из гугла. Для решения проблем с utf8 есть дистр msysgit с поддержкой unicode. На момент написания этого коммента, самым свежим был этот code.google.com/p/msysgit/downloads/detail?name=Git-1.7.8-preview20111229-unicode.exe

[@willka]

Статья — просто класс! Обожаю такой материал: всё вместе, всё по теме и полно.
Спасибо, большое.

[@kuchumovn]

Вот ссылка на правильный софт: code.google.com/p/utf8-git-on-windows/downloads/list

[@Hwd]

Git Bash.
Пробовал всё, что описано в статье. Однако результат нулевой. Смотрю содержимое текстовых файлов:

cat ansi.txt
cat utf-8.txt

Корректно отображается кириллица в содержимом только того файла, кодировка которого совпадает с кодировкой окна Options:



По мотивам проблемы создал две темы на stackoverflow: первая, вторая.

[@YakovLitvin]

Пока что не удалось справиться с проблемой. Вы не могли бы описать «стэк» программ, которые пересылают текст друг другу (как я понимаю, это по крайней мере сам git, pager и cmd) и какие настройки на что влияют, чтобы можно было как-то это отладить?

[@axi1]

git --no-pager diff |less

[@axi1]

или LESSCHARSET=utf-8

[@delphinpro]

pager = cat|more.com

Жалуется на неизвестную команду more.com
Вариант pager = cat|more отработал нормально.