Публикации с меткой «git»

Введение

Today I want to tell you about quite interesting project from the GitHub. It is developed by Hilary Mason and called gitmarks.

This project allows to save URLs and share them with other GitHub users. For each bookmark, script downloads page's content. Also, you could specify the tags and description of the link. All data are saved to the git repository and commited, and of cause you is able to use git grep to search over all saved bookmarks. URLs could be added from the command line or using a bookmarklet, but in the latter case your have to start a local web server.

Image by Ei! Kumpel.

However, this project have a few shortcomings.

First, the code looks ugly because Hilary ignores naming conventions, accepted by Python community.

Secondly, existing documentation says nothing were to store bookmarks. Because of that, many people start to fork the repository and to save bookmarks in it. Look at the network graph, it is quite cluttered with bookmark commits and it is very hard to find code changes in this heap.

It worse to enforce code and content separation, to make script development easier.

And finally, there are batch of small things which are inconvenient. For example, people could comment bookmarks of each other, using the GitHub's commit comments. However, right now commit page looks very scary because it include a full HTML downloaded from the bookmarked URL. To avoid this HTML have to be converted into the readable text.

I hope, this project will evolve to the usable distributed bookmarks service.

from appsettings import app
settings = app.settings.your_app

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git. А StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки, изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, SSH, или HTTP сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. HTTP метод доступа, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использование существующих конфигураций сетевых фильтров.

cd /usr/ports/devel/git
make && make install

$sudo adduser gituser

$git clone git://eagain.net/gitosis.git
$cd gitosis
$sudo python setup.py install

$ssh-keygen -t rsa

#cd /usr/ports/security/sudo ; make install clean
#rehash
#sudo -H -u gituser gitosis-init < />Initialized empty Git repository in /tank/gitrepos/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /tank/gitrepos/repositories/gitosis-admin.git/

sudo chmod 755 ~/repositories/gitosis-admin.git/hooks/post-update

$git clone gituser@YOUR_SERVER_HOSTNAME:gitosis-admin.git
$cd gitosis-admin

#su gituser
$cd ~/tmp
$git clone ~/repositories/gitosis-admin.git gitosis-admin
$cd gitosis-admin

[group projectteam]
members = vasya
writable = project

>ssh-keygen -C “vasya” -t rsa

git add keydir/vasya.pub
git commit -a -m "Allow vasya write access to project"
git push

$mkdir ~/repositories/project.git
$cd project.git
$git --bare init

#su gituser
$cd ~/tmp
$git clone ~/repositories/project.git project
$cd project
$echo "test" > test
$git add test
$git commit -a -m "initial branch"
$git push origin master

>git clone gituser@SERVER:project.git

loglevel=DEBUG

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git. А StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки, изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, SSH, или HTTP сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. HTTP метод доступа, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использование существующих конфигураций сетевых фильтров.

cd /usr/ports/devel/git
make && make install

$sudo adduser gituser

$git clone git://eagain.net/gitosis.git
$cd gitosis
$sudo python setup.py install

$ssh-keygen -t rsa

#cd /usr/ports/security/sudo ; make install clean
#rehash
#sudo -H -u gituser gitosis-init < />Initialized empty Git repository in /tank/gitrepos/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /tank/gitrepos/repositories/gitosis-admin.git/

sudo chmod 755 ~/repositories/gitosis-admin.git/hooks/post-update

$git clone gituser@YOUR_SERVER_HOSTNAME:gitosis-admin.git
$cd gitosis-admin

#su gituser
$cd ~/tmp
$git clone ~/repositories/gitosis-admin.git gitosis-admin
$cd gitosis-admin

[group projectteam]
members = vasya
writable = project

>ssh-keygen -C “vasya” -t rsa

git add keydir/vasya.pub
git commit -a -m "Allow vasya write access to project"
git push

$mkdir ~/repositories/project.git
$cd project.git
$git --bare init

#su gituser
$cd ~/tmp
$git clone ~/repositories/project.git project
$cd project
$echo "test" > test
$git add test
$git commit -a -m "initial branch"
$git push origin master

>git clone gituser@SERVER:project.git

loglevel=DEBUG

Today I wrote a simple python script, which uses GitHub's API, to retrive information about user's projects and their watchers/forkers count.

The script is pretty simple and uses lxml to get and parse XML page:

import sys
from lxml import etree as ET

username = 'svetlyak40wt'

if len(sys.argv) == 2:
    username = sys.argv[1]

url = 'http://github.com/api/v1/xml/%s' % username
data = ET.parse(url)
reps = data.findall('repositories/repository')

if reps:
    tmpl = '%25s, %8s, %5s'
    print tmpl % ('NAME', 'WATCHERS', 'FORKS')
    for rep in reps:
        print tmpl % (
            rep.find('name').text,
            rep.find('watchers').text,
            rep.find('forks').text,
        )
else:
    print 'User %s has no repositories.' % username

Feel free to fork this Gist and modify it.

By the way, after work was done, I've found that Gabriel Horner already done same task few weeks ago, but he implemented it as a bookmarklet.

Using these tools, I found, the top 5 of my most popular apps:

• django-tagging-ng — 30 watchers and 1 fork
• django-perfect404 — 12 watchers
• django-faces — 9 watchers
• django-pingback — 9 watchers and 1 fork
• gtdzen — 7 watchers and 1 fork

Not bad! :-)

Today I wrote a simple python script, which uses GitHub's API, to retrive information about user's projects and their watchers/forkers count.

The script is pretty simple and uses lxml to get and parse XML page:

import sys
from lxml import etree as ET

username = 'svetlyak40wt'

if len(sys.argv) == 2:
    username = sys.argv[1]

url = 'http://github.com/api/v1/xml/%s' % username
data = ET.parse(url)
reps = data.findall('repositories/repository')

if reps:
    tmpl = '%25s, %8s, %5s'
    print tmpl % ('NAME', 'WATCHERS', 'FORKS')
    for rep in reps:
        print tmpl % (
            rep.find('name').text,
            rep.find('watchers').text,
            rep.find('forks').text,
        )
else:
    print 'User %s has no repositories.' % username

Feel free to fork this Gist and modify it.

By the way, after work was done, I've found that Gabriel Horner already done same task few weeks ago, but he implemented it as a bookmarklet.

Using these tools, I found, the top 5 of my most popular apps:

• django-tagging-ng — 30 watchers and 1 fork
• django-perfect404 — 12 watchers
• django-faces — 9 watchers
• django-pingback — 9 watchers and 1 fork
• gtdzen — 7 watchers and 1 fork

Not bad! :-)

I have a project on GitHub. It's name is django-vcs-watch. Also, I had a test django project in separate directory. This test project was a separate git repository, but today I decided to made it a part of [django-vcs-watch] and include as example project to the main repository at GitHub.

So, I started to search how to merge two git repositories together. And furtunately, I have found the solution. See the comments for this post, where Tobu suggests to use git filter-branch and pulling to get two repositories together.

First, full vcs_test projects content was moved to a new subdirectory example, using this command:

git filter-branch --index-filter 'git ls-files -s | sed "s-\t-&example/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD

Next, I'm went to the django-vcs-watch directory, and just make a pull:

git pull ../vcs_watch/

That's it! Just one git push, and all changes will go to the GitHub. Hey! They are already there!

Note, that git-filter-branch has other interesting applications. For example, you can split you repository, or remove some unwanted commits. Anyway, this command is very dangerous, don't try to repeat these experiments at home, or at least, have a backup :-)

Я уже довольно давно собираюсь написать хоть какое-то примерное сравнение этих двух систем контроля версий - просто потому, что меня это касается довольно прямым образом. Но постоянно не мог собраться - сомнения, как бы начать, достаточно ли я для себя точек сравнения накопил, и так далее... В конце концов решил не тянуть резину в долгий ящик и написать то, что есть. Возможно, если получится мало и спорно, в жарких дискуссиях начнёт просыпаться истина... эээ... это я как-то отвлёкся от темы, приступим к делу. :-)

Итак - два участника. Git - более гиковский (в представлении его создателей и фанов ;), и Mercurial - написанный на питоне. Аргументы абсолютно ортогональные друг другу, но дело в том, что я всегда тяготел к более гиковским программам - однако логично, что я сейчас тяготею к программам, написанным на питоне. :-) Однако оказалось, что гиковость выразилась в довольно неожиданном (как для меня) виде - абсолютно не в виде нестандартного, более мощного, интерфейса, а в виде... Удачное высказывание - грех не процитировать:

dottedmag: UI неконсистентен совсем

Абсолютно неконсистентен. Можно плюнуть на 146 (!) файлов в /usr/bin (из которых больше ста - компилированные бинарники): они, типа, соответствуют никсовой философии "одна утилита для одной задачи" (на мой взгляд, git в общем выполняет очень даже одну задачу - хранение версий моих данных) - это, кстати, собираются вроде в скором будущем поправить. Но самый простой пример - выбивает из колеи. Для меня являлось нормальным создавать клон репозитория удалённо простой командой:

hg clone byteflow ssh://piranha@piranha.org.ua/dev/byteflow

Репозиторий клонирован. Я могу, опять же по ssh, забрать его. Могу настроить web-доступ для него (опять же, если я настроил весь ~/dev/ показывать в веб-морде, и без этого можно обойтись). В git'e... читаем хелп:

<repository>
The (possibly remote) repository to clone from. See the URLS section below for more information on specifying repositories.
<directory>
The name of a new directory to clone into.

Это мелочь. Я могу поставить sshfs (ха, если я не в винде сижу!), и склонировать как будто бы в локальную директорию. Но эти мелочи идут сквозняком через весь интерфейс git'а, что приводит к значительно более раздражающей меня проблеме - адресам у веб-интерфейса. Достаточно сравнить:

• http://git.catap.ru/?p=emacs-jabber.git;a=blob;f=jabber-chatbuffer.el;hb=HEAD
• http://hg.piranha.org.ua/byteflow/file/tip/urls.py

Из обоих убраны идентификаторы ревизии (заменены на символические аналоги последней ревизии - HEAD и tip). Что легче прочитать? Запомнить? Я очень часто набираю ссылки по памяти, но с git'ом этот фокус провернуть на порядки сложнее.

Ещё одна проблема с адресами - у меркуриала один и тот же адрес является адресом веб-интерфейса и адресом для самого клиента меркуриала: надо помнить лишь один адрес. С гитом этот номер не прокатит - попробуй догадайся про адрес у первого репозитория без подсказки? Тут повезло, всего лишь git://git.catap.ru/emacs-jabber. Но... интерфейс, это интерфейс...

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

Продвигаемся вперёд по плану гнобления¹: набор команд. Не видел ни разу человека, набиравшего команду status полностью - все пишут st. Обломитесь - в гите нельзя сокращать команды. Нету автоматических (ну конечно, всегда можно сделать алиасы) st, ci, и вообще никаких сокращений команд - при этом в меркуриале кроме предустановленных сокращений хватает любого набора букв, достаточного для несомненного определения команды.

А что мы можем сказать о помощи? У систем огромное количество команд и возможностей. Помощь в меркуриале - это информация по сути дела. hg help clone - одна страница с описанием поведения при разных условиях и списком специфических опций. git help clone - 4 страницы текста. Зачем мне столько? Я хочу краткий хелп, а не руководство. Руководство должно быть в man-pages или в виде книжки. Когда у меня есть только медленная консоль, это не может не раздражать.

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

К завершению подойду полупинком (почему "полу" - об этом позже) в сторону меркуриала. В гите есть довольно удобная штука в виде бранчей. Это что-то типа внутрирепозиторийных клонов (можно провести прямую аналогию с директориями trunk и branch, являющихся обычным приёмом при работе с svn). Самый большой прикол заключается в том, что бранчи в полный рост реализованы в меркуриале - но никаким образом не реализована удобная работа с ними:

• hg fetch (который является склеенным скачиванием обновлений и автоматическим их мержем) может поломаться, когда изменения для мержа есть в нескольких ветках.
• tip стоит не на основной ветке, а на последнем коммите.
• hg backout не проверяет, из текущей ли ветки запрашиваемый чейнджсет, или нет.
• hg push определяет создание нескольких "голов²" только для текущей ветки.

Почему это полупинок? По двум причинам:

1. На большинство проблем уже заведены баги, и работа над ними ведётся, хотя это и слабая отмазка. :-)
2. В большинстве случаев использование бранчей неоправданно и их замена обычными клонами (отдельными репозиториями) создаёт куда более прозрачный цикл работы.

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

В принципе, замечания по поводу "это лучше, а это хуже" - приветствуются, особенно личные и субьективные (субьективные не в плане "я щетаю шо субверсион рулед и капец!" ;). Ссылки на статьи... я бы предпочёл пережёванные мысли комментирующих, потому что статей уже сам почитал - пока ни одной вменяемой git vs hg, где гит был лучше, не видел. В основном фанаты какие-то.

P.S. Тут в статье случайно мелькнуло слово svn. Чтоб развеять сомнения в моей ориентации, спешу сообщить - я натурал, svn ненавижу за крайнюю угрёбищность и перманентную порчу последнего года жизни. :-)