Совместный доступ исходникам

Моя проффесиональная деятельность в основном связана с Linux, хотя последние 6 лет на рабочем компьютере установлена Windows. Я делал несколько попыток пользоваться WSL, когда он только появился в Windows, но каждый раз опыт был негативный. Частые зависания подсистемы Linux и приходилось перезагружать Windows. Не работал Docker и некоторые другие программы. В то же время у меня появилась виртуальная машина VirtualBox с Debian внутри, которая после нескольких обновлений работает и по сей день. Вначале я пользовался shared folders в VirtualBox чтобы была возможность запускать IDE в Windows, но запускать программы в Linux. Это работало, но с определенными проблемами.

Поскольку в Windows выполнялось только редактирование файлов, то рациональным решением стало переносом их на сторону файловой системы Linux, а Windows становилась клиентом. Для этого я настроил NFS сервер в Linux и подключал его через NFS клиент Windows. С таким подходом тоже были нюансы, но такая схема успешно продержалась до прошлого года. Определенную головную боль приносило создание директорий в Windows (т.к. при монтировании в Windows использовалась опция -o fileaccess=644, то директории создавались, но зайти в них было нельзя), но если создавать их в Linux, то все работало нормально. Еще где-то полгода назад появилась проблема с сохранением файлов из Windows (ругалось что файл занят и запись невозможна, но кроме Windows с этим файлом никто не работал) - возможно виноват какой-то из дополнительных "агентов", которые установлены на рабочем компьютере.

Миграция etckeeper с mercurial на git

В начале 2012 года я начал использовать etckeeper для отслеживания изменения в /etc. Тогда я использовал Mercurial в качестве системы контроля версий и было очевидным использовать его в качестве бэкенда хранения для etckeeper.

Двумя годами позже я сменил место работы и целиком переключился на Git. Все новые инсталляции уже использовали Git для etckeeper, но домашний сервер и ноутбук все еще оставались на Mercurial. Где-то в районе выхода Debian Jessie ноутбук перешел на Git при миграции с i386 на amd64. А сервер оставался на Mercurial до сегодняшнего дня, но несколько попыток починить такую ошибку привели к миграции:

/etc/cron.daily/etckeeper:
abort: path contains illegal component: .hg/undo.dirstate
abort: path contains illegal component: .hg/undo.backup.dirstate
abort: path contains illegal component: .hg/undo.dirstate
abort: path contains illegal component: .hg/undo.backup.dirstate

Когда-то я уже описывал процесс миграции с Mercurial на Git с использованием расширения hg-git, но в этот раз решил попробовать сделать по инструкции с git-scm.com

Сделать файл выполняемым в Git

По-умолчанию Git не сохраняет права доступа на файлы, но есть возможность сделать отдельный файл исполняемым

$ git add script.sh

$ git ls-files --stage script.sh
100644 9f3f770bfcccad3d62d2e2d08b077469ef3722fa 0       script.sh

$ git update-index --chmod=+x script.sh

$ git ls-files --stage script.sh
100755 9f3f770bfcccad3d62d2e2d08b077469ef3722fa 0       script.sh

$ git commit -m 'Executable script'
[master (root-commit) 1cf26b3] Executable script
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100755 script.sh

Ошибка Git при попытке пушить новый бранч

Коллега пожаловался на ошибку Git при попытке запушить новый бранч:

remote: error: failed to lock refs/heads/dev/feature1
To https://example.com/repos/project.git
! [remote rejected] dev/feature1 -> dev/feature1 (failed to lock)
error: failed to push some refs to 'https://example.com/repos/project.git'

Ответ нашелся тут. Дело в том, что в репозитарии уже был создан бранч "dev" и создавать новый бранч dev/feature1 отказывалось, т.к. бранч "dev" создается в виде файла, а бранч "dev/feature1" в виде директории dev в которой будет находиться файл feature1. В этом случае возникает конфликт "dev" как файл и "dev" как директория.

Скорость работы Git на сетевых дисках

В компании, где я работаю, для разработки используется центральный сервер. На этом сервере в контейнерах настроены различные конфигурации веб-серверов и баз данных. Исходники подключаются к рабочим станциям через сетевые диски (samba), sshfs или NFS. Самый популярный вариант - samba.

Началось все с проблем с большими репозитариями (297MB и ~15k файлов). При работе с подобным репозитарием и на локальном диске все неспешно, а на сетевом - совсем беда. Чтобы понять суть проблемы небольшой тест производительности команды git status на одном и том же репозитарии, но подключенном в Linux и Windows. В Linux используется CIFS, а в Windows - сетевой диск.

В качестве одной из оптимизаций в Windows будет использоваться core.fscache = yes:

git config --global core.fscache yes

	Real	User	Sys
Linux	0m5.927s	0m0.304s	0m1.052s
Windows	2m37.809s	0m0.000s	0m0.406s
Windows/core.fscache=yes	0m30.732s	0m0.000s	0m0.031s

Включение core.fscache дает пятикратный прирост в скорости работы Git в Windows на сетевых дисках. Пока никаких побочных явлений, связанных с включением этого параметра не замечено. Вариант с Linux в комментариях не нуждается - там все ожидаемо быстро и без этой опции.

Скорость работы Git в Windows

Не новость, что Git в Windows работает хуже, чем в Linux. Этому есть несколько причин - от различий в архитектуре кеша файловой системы до различий в скорости работы транспорта ssh. Я решил сделать сравнение скорости клонирования довольно большого репозитария с использованием различных транспортов: http, ssh/plink и ssh/openssh. Результаты тестирования в виде таблицы:

Транспорт	Real	User	Sys
https	23m45.544s	0m0.000s	0m0.015s
ssh/openssh	12m18.379s	0m0.000s	0m0.030s
ssh/plink	87m21.428s	0m0.000s	0m0.015s

В итоге получилось, что самым выигрышным вариантом является ssh/openssh, а используя ssh/plink придется ждать в 7 раза дольше!

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

Транспорт	Real	User	Sys
https	0m49.125s	0m0.000s	0m0.000s
ssh/openssh	0m49.483s	0m0.000s	0m0.015s
ssh/plink	1m51.556s	0m0.000s	0m0.000s

Внутри локальной сети ситуация поменялась - скорость https и ssh/openssh практически не отличается, а ssh/plink сократил отставание до 2-х раз. Таким образом при быстром соединении можно жить и с plink в качестве транспорта, но посколько большинство репозитариев все же находятся далеко, то лучше использовать вариант с openssh.

Hint: Чтобы использовать ssh-agent.exe из openssh в Windows нужно:

• добавить в пользовательские переменные окружения SSH_AUTH_SOCK=/tmp/.ssh-agent
• настроить автозапуск C:\Program Files (x86)\Git\bin\ssh-agent.exe -a /tmp/.ssh-agent
• добавить ключ в ssh-agent (например: ssh-add %USERPROFILE%\.ssh\id_rsa)

Недостаток этого подхода - отсутствие GUI для управления ключами в ssh-agent.

И напоследок: клонирование этого же репозитария в Linux в локальной сети занимает всего 9 секунд...

Reverting merge in git

Чтобы отменить неудачный мерж в git нужно узнать его sha-хеш в логе и выполнить git revert -m 1 %hash%. Параметр -m требуется чтобы указать git какого из родителей мерж комита нужно оставить.

$ git revert -m 1  975a217272bb91fd 
[master 268298c] Revert "Merge branch 'fix_permissions' into 'master'"
 99 files changed, 3222 insertions(+), 4898 deletions(-)

При этом в истории появится что-то вроде этого:

commit 268298ce95363a2c0c383c2249d4836617484dc5
Author: Andrey Tataranovich <tataranovich@gmail.com>
Date:   Wed Jul 15 16:17:09 2015 +0300

    Revert "Merge branch 'fix_permissions' into 'master'"
    
    This reverts commit 975a217272bb91fd5cd32cc6ea4ea9af189fbcc2, reversing
    changes made to 0c2c54e1a29576afd760bbdaa7f986f14c2c28cd.

commit 975a217272bb91fd5cd32cc6ea4ea9af189fbcc2
Merge: 0c2c54e 4eb3dd6
Author: John Doe <john.doe@example.com>
Date:   Wed Jul 15 14:15:03 2015 +0300

    Merge branch 'fix_permissions' into 'master'
    
    fix permissions
    
    fix permissions
    update order-notes-and-files
    
    See merge request !12

Осталось запушить изменения на сервер. Более подробную инфу по отмене мержа можно найти тут.

Ошибка "error: RPC failed; result=22, HTTP code = 411" при git push

Если вы делаете git push в репозитарий, доступный по HTTP или HTTPS, и получаете ошибку вида:

$ git push origin master
Pushing to https://git.example.com/repos/test.git
POST git-receive-pack (chunked)
error: RPC failed; result=22, HTTP code = 411
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Everything up-to-date
Completed with errors, see above

то вам поможет увеличение значения параметра http.postBuffer (значение по-умолчанию: 1MB). Чтобы увеличить значение до 50MB выполните

$ git config --global http.postBuffer 52428800

Решение подсмотрено на stackoverflow.com.

Конвертирование репозитария из mercurial в git

Относительно недавно довелось переводить один из внутренних проектов с mercurial на git. На всякий случай я делал миграцию на копии репозитария, чего и вам советую во избежание всяких неожиданностей.

Итак, сначала делаем копию репозитария (я добавляю опцию --noupdate, чтобы скопировать только метаданные)

$ hg clone --noupdate project.orig project.hg

Затем нам нужно установить расширение hg-git и подключить его в ~/.hgrc. В дебиан для этого нужно установить пакет mercurial-git

$ sudo aptitude install mercurial-git
$ cat >> ~/.hgrc <<_EOF_
[extensions]
hgext.bookmarks =
hgext.git =
hgext.convert =
_EOF_

Инициализируем пустой git репозитарий (тут нужно обратить внимание на опцию --bare, иначе hg push закончится ошибкой "прервано: git remote error: refs/heads/master failed to update"

$ mkdir project.git
$ git init --bare project.git/.git
Initialized empty Git repository in /home/andrey/tmp/hg-to-git/project.git/.git/

Если нужно скопировать информацию о ветках, кроме default, то нужно сначала добавить соответствующие bookmarks в репозитарии mercurial

$ cd project.hg
$ hg bookmark -r default master
$ hg bookmark -r feature1 feature_1
...

Когда все будет готово настает время выполнить push из репозитария project.hg в project.git

$ cd project.hg
$ hg push ../project.git
проталкиваем в ../project.git/
creating and sending data

На большом репозитарии этот процесс может занять много времени и потребовать достаточный объем оперативной памяти. Если процесс завершился без ошибок, то пора проверить историю комитов и соответствие бранчей в project.git

$ cd project.git
$ git log -n 1
commit 2c765e70ad96c2bd2bc6cc0b545038f4faa42c25
Author: John Doe <john.doe@example.com>
Date:   Sun Apr 20 12:27:44 2014 +0300

    Latest fixes for reviews.

$ git branch
* master
  feature_1

Теперь все готово и можно работать с репозиторием через git.

Как в Git просмотреть файл целиком из определенной ревизии

Начинаю осваивать Git в качестве альтернативы Mercurial - потребовалось просмотреть файл целиком за определенную ревизию. В Mercurial для этого есть "cat", т.е.

$ hg cat -r 2fad6072a89d path/to/file

в git для этого есть команда "show"

$ git show -r 269c3b6ca51a:path/to/file