Как стать автором
Обновить

Комментарии 16

На самом деле, что в Git, что в Mercurial, с кодировкой имён файлов под Windows всегда были проблемы.


Простой опыт. Попробуйте закоммитить файлы под Windows, а потом склонировать на Linux. Или в обратную сторону. Все не LATIN символы будут покорёжены.


Так что если над проектом работают люди из разных OS, то только английская кодировка. Увы...

Случай с разными операционками я морально ещё как-то готов принять, могут быть проблемы с допустимостью символов, с регистром этих символов. Но не полностью — UTF8 и в Африке UTF8. Попробую, кстати, на виртуалке проверить, как себя поведут сконвертированные репозитории.
Проверил под Debian, файлы отображаются корректно. Там может быть момент, связанный с содержимым (cr/cr+lf), но это давно научились решать.

А вот это уже действительно интересно...

Проблема в том, что в битбакете кроме собственно содержимого mercurial-репозитория, может быть и другая информация, например, тикеты. У меня были такие проекты на mercurial с многолетней историей. Если пересоздавать проект с GIT-репозиторием, то все это потеряется. В конце концов, Atlassian могли бы предоставить инструмент конвертирования mercurial репозиториев в git, чтобы проекты оставались неизменными. Но они это не сделали. Видимо, посчитали нерентабельным и нецелесообразным. Ну и я тоже посчитал дальнейшее пребывание у них нерентабельным и нецелесообразным и несмотря на то, что у меня был у них платный аккаунт с 2007 года, перенес свои проекты на self-hosting на базе RhodeCode
Справедливости ради, Atlassian и GitHub предоставляют такой инструмент, но, как я понимаю, из-за старой проблемы с кириллицей именно в Mercurial, кириллические файлы стандартными инструментами ломаются.

Касательно тикетов — тикеты я перенёс из встроенного инструмента BitBucket в Jira и мне этого хватило — они интегрируются по номеру тикета в описании коммита, после переезда Mercurial->Git ссылки работают.

Ну и self-hosting не панацея, если производитель движка (тот же RhodeCode или BitBucket Server) решит забросить поддержку одного типа репозитория, то придётся либо переезжать, либо застревать на неподдерживаемой версии движка.
self hosting очень похож на панацею Хотя бы потому что ничто не мешает оставаться на старой версии пока не напишется инструмент конвертирования. А с битбакетом вообще некрасиво получилось. Они метлой выгоняют всех пользователей меркуриала без возможности остаться. И вроде пользователей меркуриала всего 1 процент но это сотни разработчиков и тысячи репозиториев.
Self Hosting — это оттягивание решения на чуть более долгий срок. Потому что клиенты тоже развиваются, может статься, что придётся иметь два клиента — один для своих репозиториев, второй для сторонних (флиланс/доступ к опенсорсам в облаке). Ну и вопрос правки багов/безопасности тоже остаётся. К примеру, работа с https сейчас прогрессирует, закрываются старые tls 1.0 и 1.1, и это, наверняка, не конец. Может статься, что пропатченная операционка не даст подключиться к серверу с исходниками. СУБД, опять же, придётся старую в продакшене держать… В общем, много вариантов, где это может выскочить.

Эмоционально — да, я согласен, что уход от Меркуриала неприятен, но с точки зрения бизнеса это верное решение. У меня был вариант раньше переехать полностью на Гит, но бизнес-решение было остаться. Чуть ниже — некоторые из причин.

Касательно победы Гита над Меркуриалом — тут не во всём понятное для меня явление. По всем тестам, которые публиковал Битбакет, Меркуриал работал быстрее. И в плане бытовом он мне больше нравился (сложнее «запороть» репозиторий, чуть понятнее функционал). В общем, как первая распределенная система контроля версий в жизни начинающего программиста, он, на мой взгляд, лучше. Но это уже холивар и оффтопик ;)
К сожалению инструмент GitHub у меня «не пошел» не только с кириллическими файлами, но и со всеми кириллическими комментариями…
Скрин
image
Жесть. У меня комменты выжили. Метод из статьи не пробовал? Мне любопытно, насколько универсальное решение получилось :)
завал на работе, особо пробовать/разбираться некогда было, с наскока не вышло, пока отложил
Правильно ли я понимаю, что данный рецепт исправит имена файлов только в последнем коммите? А если выписать файлы из старого коммита, то там имена файлов будут испорчены?
Если так, то без всяких дополнительных инструментов, можно взять из репозитория hg файлы с русскими именами, скопировать в рабочую директорию git, предварительно удалив все файлы из рабочей директории (включая файлы с испорченными именами), и гитом сделать коммит «fix filenames». Но дело в том, что при этом проблема то остаётся, нельзя получить старое состояние с корректными именами файлов.
1. Да, у меня файлы в старых коммитах так и отображаются побитыми.
2. Думаю, что удаление файлов в каталоге git и копирование в него всех файлов из hg должно тоже работать, но будут ли какие-то различия — не скажу, хорошо бы проверить.

(не)Забавное наблюдение — посмотрел самый старый свой репозиторий, от декабря 2010 года, там первая заливка корректно показывает имена файлов и актуальный Sourcetree прекрасно с ними работает. А чуть позже в репозитории есть коммит «починка кодировки», где все файлы с кириллицей сломаны. Точно не помню, но есть подозрение, что именно тогда я переехал с хостинга на своём компе на облако Bitbucket и их дефолтные настройки всё сломали. Репозитории, которые изначально создавались на Bitbucket, сломаны с самого начала.
Получилось сконвертировать из Mercurial в Git репозиторий, содержащий русскоязычные имена файлов, и созданный на TortoiseHg 3.5.2 под Windows.

Конвертация удалась на версии TortoiseHg 5.0.2 (на многих других версиях, как более старых, так и более новых, конвертация оказывалась невозможна, где то расширение hg-git не работает, где то ещё что то). Эта версия под винду включает в себя расширение hg-git, никаких других расширений устанавливать не было необходимости.

Перед тем, как пушить репозиторий в Git, для корректного формирования имён файлов в репозитории Git, нужно воспользоваться функцией hg convert, переименовав файлы, фактически преобразуя кодировку имён путём переименования. И из полученного в результате этой операции промежуточного репозитория Mercurial с именами файлов в utf-8 уже нужно делать пуш в новый bare (обязательно bare!) репозиторий Git. Пуш я делал из графического интерфейса TortoiseHg. На том, как делать пуш, как включить расширение hg-git, не останавливаюсь, эту информацию легко найти.

Для операции hg convert с преобразованием кодировки понадобится файл rename.txt с командами преобразования каждого файла. rename.txt был получен с помощью команды hg manifest и вспомогательного файла rename.py.

Содержимое файла rename.py:
import sys
for path in sys.stdin:
old = path[:-1] # strip newline
new = old.decode(«cp1251»).encode(«utf-8»)
print 'rename "%s" "%s"' % (old, new)

Команда, которая сформирует rename.txt (текущей должна быть директория исходного репозитория):
hg manifest --all | python rename.py > rename.txt

Здесь нужно иметь в виду, что вышеуказанный rename.py предназначен для питона версии 2.7, и в моём случае питон этой версии был установлен дополнительно, и вызов выглядел так:
hg manifest --all | C:\prog\Python27\python.exe rename2.py > rename.txt

В результате файл rename.txt должен выглядеть так, что будучи просматриваемым в кодировке 1251, будут читаться русскоязычные имена файлов в части команды, указывающей что переименовываем, а при просмотре в кодировке utf-8 должны читаться русскоязычные имена файлов в части команды, указывающей во что переименовываем. Зная, каким должен быть файл rename.txt, желающие могут изменить rename.py под современную версию питона.

Получив rename.txt, остаётся выполнить команду:
hg convert --filemap rename.txt src-repo tmp-repo
где src-repo это исходный репозиторий, а tmp-repo это промежуточный репозиторий Mercurial с именами файлов в utf-8.

После чего сделать пуш из tmp-repo в вновь созданный bare репозиторий Git.
История коммитов сохраняется?

Да, в истории коммитов всё есть, русские имена показывает правильно. Если обнаружу какие косяки, тут напишу.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.