понедельник, 30 января 2012 г.

Скрипт Ruby для вычисления SHA1 по аналогии с Git



Некоторое время назад, участвовал в одном обсуждении.
Тогда же, по его результатам, родился небольшой скриптик.
Вкратце, это действует так.
Если вы когда-то давным-давно закоммитили файл. Потом имя (но не содержимое) этого файла несколько раз менялось.
А сейчас вам необходимо найти содержимое блоба, зная только текущее наименование файла.

Следующий скрипт должен помочь.


Выполните:
$ git-sha1.rb filename1 filename2 ... filenameN

На выходе получите список хешей:
sha1_1
sha1_2
...
sha1_N

Теперь можно попробовать найти нужный блоб.
$ git show sha1_N

Так же исходный код этого срипта можно взять на гитхабе.

пятница, 20 января 2012 г.

Cygwin: Starting Gerrit Code Review: Error: Unable to access jarfile


When you encountered this error then you should search in the file "bin/gerrit.sh" for string Если вы встретили такую ошибку, то необходимо в файле "bin/gerrit.sh" найти строку 

GERRIT_SITE=`pwd`

and replace it to the next string и заменить на следующее

GERRIT_SITE=`cygpath -am \`pwd\``





четверг, 12 января 2012 г.

MacOSX: Unicode в названиях файлов в HFS


Недавно, я столкнулся с тем что Git на свежевыкачанном репозитории SVN упорно считает, что некоторые файлы находятся в состоянии Untracked.
Небольшое расследование вывело на следующее.

Unicode позволяет, если не совсем избавиться, то минимизировать проблемы национальных кодировок.
Большое число символов задаётся одним единственным кодом.
Но также имеется немаленькое количество знаков, которые составляются из пар кодов.
Наглядный пример, азиатские языки или различные служебные модификаторы вроде признака направления письма справа-налоево или знака ударения.

Кириллица не стала исключением.

При создании файлов, содержащих в наименовании композитные буквы, HFS сохраняет эти названия в виде двух отдельных знаков.

Для меня это стало сюрпризом, т.к. хотя по спецификации всё верно: буква "Й" является композицией следующих двух:

Тем не менее, буква имеет и единичный код

Аналогично и для "Ё".

Если невооружённым взглядом такое поведение или сложно или невозможно, то оно прекрасно наблюдается во время SSH-сессии.

Локально из терминала проблему можно воспроизвести если создать какой-либо файл, например:
$ touch Ё-моё.txt
И попровать затем выполнить автодополение клавишей [TAB].
$ ./Ё[TAB]
не срабатывает.

Но если ввести
$ ./Е[TAB]
то мы увидим нашу многострадальную "Ё".

Некоторые программы (в моём случае GIT и SVN) не могут корректно обработать такую ситуацию.
Файл, по-мнению алгоритмов, просто не существует.
То есть один и тот же файл в репозитории (попавший туда из других файловых систем) и хранящийся локально (в HFS) считается двумя разными файлами.

Пока мне не попалось подходящего решения или обходного пути.
И, похоже, что необходимо заводить тикет с багой.


Далее, можно почитать про проблему длинных имён в HFS+