Friday, February 18, 2011

Мои git alias'ы

Решил тут написать алиасы, которые я использую в гите:

$ cat ~/.gitconfig
...
[alias]
di = diff --no-prefix
ll = status
fast-fix = !"git diff && read -p \"ready to commit?\" i && git commit -a && git push"


Итак по порядку:
git diff --no-prefix заменяет вывод с
--- a/path/to/file
+++ b/path/to/file

на
--- path/to/file
+++ path/to/file

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

git ll это просто аналог башевского alias ll='ls -l'

Ну и наконец самое сложное: git fast-fix
сначала делается git diff && read -p "ready to commit?" эта штука выводит текущие изменения и ждёт когда я что-нибудь нажму или же нажму ctrl+c для отмены дальнейших действий. А действия дальше какие: git commit -a который понятно что делает: просит ввести коммит мессидж, если его ввести, то произойдёт git push, если нет, то коммита не будет и как следствие пуша :)

Во-первых почему называется fast-fix? потому, что на букву f начинается не так много команд, а на fa и вовсе ниодной, таким образом я набираю git fa[TAB][ENTER], можно было бы тогда и назвать git fa, но имхо это уже не такое очевидное сокращение, как di или ll.
Во-вторых зачем так сложно? Данная команда очень удачна в случае, когда изменений минимальное количество: скажем нужно просто исправить опечатку. Тогда чтобы сделать это нужно выполнить всего 3 действия: git pull; edit somefile; git fast-fix. Ну причём первое не всегда обязательно, если вы забыли стянуть изменения, то при git push вам об этом скажут и можно будет отдельно сделать git pull; git push; Самое главное, что происходит проверка того, что вы собираетесь закоммитить: во время git diff (изменения по сравнению с working tree) и во время git commit (список файлов, по сравнению с HEAD). Во время которой может обнаружиться что-то, чего вы не ожидали :) и главное, можно будет исправить (ctrl+c в diff и пустое сообщение в git commit).
В-третьих зачем так просто? Да, когда изменений больше чем на пару строчек, то этот скрипт немного слабоват, и тут я открыт для предложений :)

Monday, February 14, 2011

gitolite+gitweb on ubuntu

В общем сейчас расскажу что у меня получилось сделать :)
Сервер git с авторизацией по ключу, с гибкой системой прав, то есть gitolite.
Закрытый по паролю доступ к веб-морде с проектами (история, просмотр кода), то есть gitweb.

Ставим

Имелась у меня убунта, сначала я поставил в неё апач и gitweb
$ sudo aptitude install gitweb apache2

Дальше ставил gitolite не из репозитория, а из исходников. Инструкция тут, но вкратце:
на своей машине
$ scp .ssh/id_rsa.pub server:/tmp/YourName.pub
на машине, где будет сервер
$ sudo -i
# adduser --disabled-password git
# git clone git://github.com/sitaramc/gitolite gitolite-source
# cd gitolite-source
# mkdir -p /usr/local/share/gitolite/conf /usr/local/share/gitolite/hooks
# src/gl-system-install /usr/local/bin /usr/local/share/gitolite/conf /usr/local/share/gitolite/hooks
# su - git
$ gl-setup /tmp/YourName.pub

Только не забываем заменять YourName на ваше имя, а server на адрес сервера.

Настраиваем gitolite

Дальше конфигурим (локальная машина):
$ git clone git@server:gitolite-admin
$ cd gitolite-admin
$ editor conf/gitolite.conf
$ git add .
$ git commit
$ git push


Собственно, что же надо было написать в конфиг:

repo testing
RW+ = @all
R = gitweb daemon

Ну в целом добавляем права на чтение для любого репа, который хотите, чтобы появился в веб-морде. Подробнее тут.
На этом наше конфигурирование не заканчивается :) нужно сменить маску для новых репов (файл .gitolite.rc)
$REPO_UMASK = 0022;
и указать пусть к .htaccess (об этом чуть позже)
$HTPASSWD_FILE = "/home/git/.htpasswd";

Настраиваем gitweb

Теперь нужно отредактировать /etc/gitweb.conf. Всего пара строчек:
$projectroot = "/home/git/repositories";
$projects_list = '/home/git/projects.list';


Правим права

Сейчас на сайте http://server/gitweb ваши репозитории не будут показываться из-за проблем с доступом. Дело в том, что хоть мы и написали маску $REPO_UMASK = 0022;, но сработает она только для новых репозиториев. Хотите доступ, нужно сделать
$ sudo chmod a+r /home/git/projects.list
$ sudo chmod a+rX /home/git/repositories/

И для репов, в которые вы хотите дать доступ (в нашем случае testing) нужно сделать
$ sudo chmod -R a+rX /home/git/repositories/testing.git, я не советую делать всё одним махом, чтобы не давать лишних прав на gitolite-admin.git

Настраиваем apache

Теперь мы вдруг понимаем, что полного доступа для всех нам не надо (в противном случае можно давно было завести аккаунт на github.com). С этим бороться будем вот так.
Для начала скажем, что доступ будут иметь только люди, у которых стоит пароль в .htaccess
для этого отредактируем /etc/apache2/conf.d/gitweb, чтобы получилось типа так:

Alias /gitweb /usr/share/gitweb
<Directory /usr/share/gitweb>
  Options FollowSymLinks +ExecCGI
  AddHandler cgi-script .cgi
  Options ExecCGI FollowSymLinks Indexes
  AuthName "git repo"
  AuthType Basic
  AuthUserFile /home/git/.htpasswd
  <Limit GET POST PUT>
    Require valid-user
  </Limit>
</Directory>
Ну и перезапускаем апач:
$ sudo service apache2 restart

Даём доступ

Права на файл /home/git/.htpasswd у меня выглядят так:
-rw-r--r-- 1 git git 21 2011-02-14 16:35 /home/git/.htpasswd, чтобы добавить какому-то юзеру доступ по паролю делаем так
$ sudo htpasswd /home/git/.htpasswd YorName, но есть более иной способ, так как на сервер пользователи уже могут попасть по ключу, то все, кто имеют такой доступ могут выполнить ssh git@server htpasswd, который определить по ключу ник и предложит установить пароль. Выглядит примерно так:
$ ssh git@server htpasswd
Please type in your new htpasswd at the prompt. You only have to type it once.

NOTE THAT THE PASSWORD WILL BE ECHOED, so please make sure no one is
shoulder-surfing, and make sure you clear your screen as well as scrollback
history after you're done (or close your terminal instance).

new htpasswd:testpass
Updating password for user YourName



Заключение

Вот так вот можно получить хороший, закрытый git-хостинг своими руками. Есть конечно куда копать: не очень понятно что делать, если хочется давать через веб-морду доступ только туда, куда у юзеров есть доступ через git. Тут есть конечно способ лечить головную боль топором: руками вписывать тех, кому можно, а изменение .htaccess запретить (убрать права у юзера git на запись или же убрать опцию $HTPASSWD_FILE). В интернетах пишут о более иных способах, но я пока не осилил :)

П.С. Если я где-то что-то накосячил, то дайте знать и я всё исправлю.

Wednesday, February 9, 2011

Начинаю вводить GTD в свою жизнь :)

Меня как-то утомила фрустрация на счёт бесцельно пролетающего времени. Сейчас объясню, что я попытался с этим сделать.
Первое, что я понял уже давно, это то, что планы на день совершенно не помогают мне эти планы выполнить. То есть если я знаю что за день мне надо что-то сделать, я аккуратненько выписываю это в google tasks, но занимаюсь почему-то тем, что там не написано --- чуть-чуть поиграю в какую-нибудь игрушку, чуть-чуть почитаю/попишу в жуйк, чуть-чуть поовощу на ютубе и т.д. и т.п.
Я решил пойти другим путём. Я по рекомендации из Radio Grinch заюзал сайт cuoluo-diary.appspot.com, но каким образом --- я начал писать там отчёты о проведённом времени. Причём сначала я пишу примерно чем я собираюсь заняться на ближайшие полчаса, а потом корректирую, таким образом, чтобы о прошлом была всегда написана правда, а о будущем планы были не сильно заоблачными. Я когда-то пытался делать это в виде google calendar, но оказывается, что гораздо проще писать в плейнтексте "10.05-10.15 разбор почты" чем сделать это в гуглокалендаре (там привязки на полчаса, как следствие сложно ввести время некратное получасу, как в примере время начала и продолжительность).
Чего я добился --- я заметил, что время перестало неожиданно исчезать, то есть теперь, когда я открываю таб с CuoLuo то там написано время не сильно отличающееся от текущего (скажем время окончания того, что я запланировал может отличаться буквально на 5 минут).
В первый день у меня была проблема, что я ставил себе задачу на ближайшие полчаса пофиксить определённый баг, а через часа полтора оказывается, что я мало того, что в это время не фиксил баг, так ещё и забыл на час о том, что я веду отчёт. Сейчас (третий день) у меня теряется максимум минут 15.
То есть подытожу. Плюсы: видно куда уходит время и получается лучше оценить что и сколько времени я буду делать в будущем (имеется в виду ближайший час, а не дни или годы конечно). Минусы: нужно быть всегда у компа (что не для всех проблема), нужно быстро печатать таймстампы :) ну и касательно "видно куда уходит время" без системы тэгов или чего-то такого, видно только здесь и сейчас. То есть нет возможности посмотреть скажем сколько процентов времени я трачу на "игры", "сон", "чатики" и т.д.