Git: выделяем глобальный репозитарий для проекта

Иногда мы копируем папку с проектом на отдельную машину, а затем пытаемся использовать его в качестве мастер-репозитария.
Но при попытке сделать пуш в этот репозитарий нас подстерегает ошибка.

$ git push origin master
Counting objects: 30, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (17/17), 3.31 KiB | 0 bytes/s, done.
Total 17 (delta 4), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /project/path
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '/project/path'

Вообще почему она возникает-то? Разве гит это не распределенная система контроля версий? Распределенная и даже чутка децентрализованная. Совсем-совсем распределенная. А это значит, что пушить изменения можно не только на одно хранилище, а вообще в любой репозитарий. Хоть чуваку за соседний комп. Таким образом разработчикии могут делиться своими наработками.

Но это подразумевает один нюанс: нельзя пушить в ту ветку удаленного репозитария с которой сейчас идет работа.

Суть сообщения в том, что в удаленном репозитарии ветвь, которую мы хотим запушить сейчас, активна (т.е. сделан чекаут на удаленной машине).

А значит и правки в эту ветвь якобы удаленной машиной вносятся (слава роботам!).

Способ первый. Мы заходим в репозитарий и просто чекаутим другую ветку проекта. Профит. :)

Способ второй. Мы узнаем, что существует два типа хранилищ: bare и non bare. Дефолтно при выполнении git init будет создано хранилище второго типа (и при чекауте чужого репощитария так же создается локальный non-bare репозитарий).

Bare значит, то это не рабочий репозитарий, а просто склад веток, куда каждый может пушить. И если мы попробуем поработать с ним напрямую (покоммитить), то нас ждет облом.

Гитхаб предоставляет хранилища именно такого типа.

Второй же тип — это репозитарии разработчика. Активная в данный момент ветвь блокируется на изменение от нелокальных клиентов.

А что делать?

Если реп у нас удаленный и для совместной работы — конвертируем его в bare

git config --bool core.bare true

Если нет — смотрим выше.

А еще можно сказать иниту, чтобы создавал bare сразу.

git init --bare

Unknown keycode 0x0

Unknown keycode 0x0Вот такая веселая надпись будет нас ожидать в gnome если установлена раскладка отличная от en_*.

А это значит, что ни один хоткей ни в одном приложении не будет работать нормально в русской раскладке.

От этого страдают все: и простые пользователи LibreOffice, и разработчики, которые вынождены пользоваться всякими разными ide, которые написаны на java.

Ага. А лечить-то как?

Для продуктов jetbrains существует два рецепта:

Добавить в idea.properties

-Dide.non.english.keyboard.layout.fix=true

Раньше работало, а теперь, увы, нет.

И второй способ, который можно использовать не только с jetbrains, но и с любым другим софтом на java.

Достаточно скачать маленький jar с гитхаба и следовать инструкции. Пока этот способ работает.

Проблема также замечена в smartsvn.

cat phpstorm.vmoptions

 

Управление зависимостями проекта при помощи bower+composer

Отлично. У нас есть новая интересная идея для нового проекта. Садимся мы значит за клавиатуру и… Эм. А что «и»? Наш проект зависит от кучи библиотек и фреймворков: yii, angularjs, doctrine, twitter bootstrap и т.д.

Ок. Открываем браузер или папочку на диске (в которой все нам нужное скачано и рассортировано) и начинаем неспешно скачивать/копировать/распаковывать.

Мы моложцы, справились. Все скопировали, но только злобные разработчики пофиксили баги и выкатили новую версию своей библиотеки, фреймворка.

Пофикшенные баги — это всегда хорошо. Начинаем процесс скачивания/распаковки заново.

Страшный сон? Кошмар разработчика? Нет-нет, что вы! Стандартная процедура, через которую проходят много-много разработчиков. И даже не задумывыются, что все это можно автоматизировать, упростить и дать себе возможность наконец-то реализовать задуманный проект, а не заниматься tar -xf или zip -u, или что у них там еще.

А ответ-то простой — это bower в связке с любым другим менеджером для вашего любимого языка (composer для php, npm для nodejs и т.п.). Больше всего мне приходится иметь дело с php, поэтому опишу на примере composer.

Опять же. Почему bower и composer. Потому что первый — это менеджер для фронтенд-составляющей, а второй — для бекенда. Композером не слишком удобно пользоваться для управления зависимостями морды приложения.

Начнем-с.

Читать далее

Заметка

Включение TRIM на SSD с LVM/LUKS

Trim — это полезная ata-команда, которая препятствует деградации производительности SSD-дисков.

Но часто случается, что дистрибутивы не включают ее на разделах.

Первым делом надо ее включить на нативных разделах просто добавив опцию discard к записи в fstab.

UUID=397b890a-c661-47f4-bd2a-2260379f8c6f /boot                   ext4    defaults,discard        1 2

Как поступать с разделами, которые расположены на шифрованных томах или lvm?

Для lvm надо сначала разрешить проброс команды trim к дискам (он запрещен по дефолту).

Правим /etc/lvm/lvm.conf и меняем опцию issue_discards с 0 на 1.

issue_discards = 1

Проверяем

$ sudo fstrim -v /home
 /home: 54,4 GiB (58440941568 bytes) trimmed

Отлично. Но что если разделы расположены на шифрованном томе, который размещен в lvm?

Важно: включение trim для зашифрованных томов может ослабить безопасность шифрования! Так как по перемещенным блокам можно сделать вывод о том, какая файловая система используется.

В /etc/crypttab нужно добавить опцию allow-discard.

luks-xxx UUID=some-uuid none allow-discards

для debian-based дистрибутивов строчка немного меняется

luks-xxx UUID=some-uuid none luks,discard

Теперь надо пересобрать initramfs.

Для rpm-based

$ sudo dracut --force

У fedora 18 есть баг из-за которого нужно указывать пусть к crypttab

$ sudo dracut --force -I /etc/crypttab

Проверим, что ctypttab был успешно добавлен в initrd.

$ sudo lsinitrd |grep crypttab

Теперь нужно заставить систему отправлять trim для томов.

# echo -e "fstrim /\nfstrim /home\nfstrim /boot" > /etc/cron.hourly/fstrim

 

Заметка

AngularJS: простой прогресс-бар

AngularJS: progressbarАнгуляр — это очень удобная штука. Но еще удобнее, когда она нормально скрещивается с другими фреймворками вроде jQueryUI.
В AngularUI я что-то прогресс-бара не нашел (знаю, искал плохо). Накропал сам.

Фидл с примером работы и исходниками.

Заметка

AngularJS: забавная особенность bindonce

Для AngularJS существует модуль bindonce, который позволяет сократить количество вотчеров и тем самым ускорить страинцу.

У этого модуля есть директива bo-attr, которая позволяет использовать в качестве атрибута элемента любое нужное нам значение. В качестве значения выступает выражение, которое будет проинтерпретировано и добавлено в dom.

Однако, у этой директивы есть забавное поведение, которое связано с особенностями интерпретации.

$scope.title = 'some text with $peci@l chars'
$scope.title_ref = 'title'
$scope.title_title_ref = 'title_ref'
<a bo-attr="" bo-attr-title="title">anchor1</a>
<a bo-attr="" bo-attr-title="{{title_ref}}">anchor2</a>
<a bo-attr="" bo-attr-title="'{{title}}'">anchor3</a>
<a bo-attr="" bo-attr-title="{{title_title_ref}}">anchor4</a>

Как думаете, что выведется в каждом случае? :)

Фидл с примером.

Заметка

tc-play. Небольшая памятка про криптоконтейнеры

Вокруг truecrypt какая-то нездоровая шумиха. Кто-то даже на трояны намекает в версии 7.1а. Так что можно попробовать свободные форки TC. Например tc-play.

Набросал себе памятку по мануалу (вы не подумайте, я их не не читаю :)).

$ sudo losetup /dev/loop1 <path to file> # делаем лупбек на файл с контейнером
$ sudo tcplay -m tc0 -d /dev/loop1 -e # делаем криптоустройство внешнего контейнера и заодно защищам скрытый том (если есть) от перезатирания
$ sudo tcplay -m tc1 -d /dev/loop1 # маппим скрытый контейнер (передаем пасс скрытого устройства

Дальше остается только примонтировать появившиеся /dev/tc* куда надо. А за остальным в мануал.