> для меня, git проще, в плане работы с несколькими равноценными вершинами. Все таки от быстрой навигации по графу отказаться не смогу.

Mercurial умеет тоже самое.

У нас так:

Есть сервер под мастер-репозитарии гита. Можно сказать, это основное место, с которого код попадет на билд сервер. Если над веткой работают несколько человек, то она пушится на центральный сервер, все изменения проходят через него, друг у друга никто не клонирует. Раздача прав и удаленный начальный пуш через gitosis.

rebase или merge веток -- решает сам разработчик.

На некоторых мастер-репозитариях стоит post-update хук, при срабатывании которого код отправляется на билд-сервер.

Вкратце все.

О, а как ты кстати сайт обновляешь с меркуриала? У меня такая схема:

1. один репо дома

2. один репо на сервере (в архиве репозиториев), в него я делаю push
из дома, его же можно смотреть через hgweb

3. в рабочей директории на серве ещё один репо, в него делается
pull из (2) (явным запуском скрипта или при старте сервиса).

Если уж припёрло делать изменения на сервере, можно сделать push из
(3) в (2), а потом pull из (2) в (1).

>О, а как ты кстати сайт обновляешь с меркуриала?

- Ядро фреймворка лежит на общедоступном репозитории (hg.balancer.ru)
- Соответственно, тестовая машина и все боевые хостинги обновляются оттуда и туда же коммитят расширения/доработки.
- Локальные сайтовые расширения фреймворка лежат на хостингах и, опционально (на простых сайтах типа «визитная карточка» такого нет) - на их тестовых машинах. Плюс на всякий случай локально у себя дома держу бэкап-репозитории таких сайтов (и не только код, но и CSS, картинки и т.п.)

Т.е. работа выглядит в разных вариантах. Например, по основной работе:
- Делаю pull & up на тестовой машине из репозитория ядра
- Написание расширений не тестовом сайте
- Опционально - правка ядра
- Тестирование расширений
- Подключение расширений
- Делаю коммиты и пуши, если надо, как для расширений, так и для ядра
- Обновляю боевой сайт с ядра и расширений
- Если при тестировании боевого сайта находятся ошибки - исправляю их сразу и делаю коммит в репозиторий уже с него.

По мелочи всякой всё проще, там без тестовых:
- pull & up ядра
- Написание расширений
- Опционально (в последний год - очень редко) - правка/расширение ядра
- Тестирование расширений
- Подключение расширений в боевом режиме
- Коммиты+пуши изменений
- pull & up расширений на домашней машине для бэкапа.

какая-то странная статья, претензии к внешнему виду одни. да и "сотни бинарей" давно уже нет.

по теме: таки в конце должен остаться только один(Гит Маклауд ящитаю).

> по теме: таки в конце должен остаться только один(Гит Маклауд ящитаю).

Не дождётесь.

<i>Питонисты</i>

._.

$ ls -1 /usr/bin/git* | wc -l
138

>да и "сотни бинарей" давно уже нет.

Anyway - это всё фигня. Почему меня должно беспокоить сколько файлов в /usr/bin?

> >> А вот объясните мне, зачем в git с его моделью, вообще нужен mq?

> > Вообще-то, если поразмыслить, не нужен. Так как есть git rebase --interactive

>  Это не то - совсем другой сценарий использования. В Mercurial есть и rebase, и mq.

Думаю, как раз-таки то. (Ну вообще-то я mq не юзал, только git-rebase -i :]).

git-rebase дает возможность не только перебазироватьродителя подветки, но и:
* отредактировать конкретный коммит в серии
* слепить коммиты
* разорвать коммиты(не очень удобно), 
* переставить их последовательность
* выбросить коммиты


Интерфейс простой: git rebase -i ancestor-branch [ну и там еще чего надо] и вываливается весь список подверженных изменению коммитов в редакторе:

собственно хелп - исчерпывающий
$ git rebase -i master

pick b0243d5 edit/syntax: added ebuild Syntax defition (taken from rhclub-tree)
pick 3906a15 Removed whitespaces on EOL in ebuild.syntax

# Rebase ffd6b19..3906a15 onto ffd6b19
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Вместо pick можно сделать с патчем что-нибудь еще.

Или у mq есть еще и другие назначения?

> $ ls -1 /usr/bin/git* | wc -l
> 138

Вроде бы с версии 1.6.0 официально забили на git-* комманды (пару штук осталось)

$ git version
git version 1.6.1

$ ls -1 /usr/bin/git* | wc -l
9

>> Это не то - совсем другой сценарий использования. В Mercurial есть и rebase, и mq.

> Думаю, как раз-таки то. (Ну вообще-то я mq не юзал, только git-rebase -i :]).

>git-rebase дает возможность не только перебазироватьродителя подветки, но и:

> * отредактировать конкретный коммит в серии

То есть rebase фактически не производится, parent первого редактируемого коммита не меняется?

> * слепить коммиты

> * разорвать коммиты(не очень удобно),

> * переставить их последовательность

> * выбросить коммиты

Тот же вопрос.

> вываливается весь список подверженных изменению коммитов в редакторе:

То есть приходится править прямо патч? O_O

> >> Это не то - совсем другой сценарий использования. В Mercurial есть и rebase, и mq.

> > Думаю, как раз-таки то. (Ну вообще-то я mq не юзал, только git-rebase -i :]).

> >git-rebase дает возможность не только перебазироватьродителя подветки, но и:

> > * отредактировать конкретный коммит в серии

> То есть rebase фактически не производится, parent первого редактируемого коммита не меняется?

если задать параметр --onto=new-parent - поменяется (у rebase немного параметров)

Пример:
git-rebase -i master --onto=my-shiny-branch
Выдерет все коммиты от master до сейчас и попытается напялить на my-shiny-branch

> > * слепить коммиты

> > * разорвать коммиты(не очень удобно),

> > * переставить их последовательность

> > * выбросить коммиты

> > Тот же вопрос.

Тот же ответ - можно менять, можно не менять. Если операция поганит промежуточный коммим - то он меняет хеш, как следствие у всех дочерних коммитов менается parent и hash.

> > вываливается весь список подверженных изменению коммитов в редакторе:

> То есть приходится править прямо патч? O_O

Нет. Git уже давным-давно юзабелен, попробуйте (снова) сами :]


В сессии редактора выбираются коммиты, и что с ними делать (как я показывал выше). Потом редактор закрывается и git пошагово воспроизводит операции (вот как в столбик в редакторе записано).

pick - накладывает патч на новосоздаваемую ветвь,
squash - сольет текущий коммит с перырущим в 1 коммит (и попросит отредактировать commit message)
edit - прервется на текущем состоянии ветки с частью закоммиченных патчей (pick) и состоянием репозитория с наложенным текущим патчем (но незакоммиченным). После модификации и коммита патча можно продолжить rebase.

Полагаю - это и есть mq + классный гитоплюшки :]
Или у mq есть еще какие-нибудь прикольные фишки?

> Тот же ответ - можно менять, можно не менять

Да, это в стиле Git - назвать rebase операцию, не меняющую base %)

> В сессии редактора выбираются коммиты, и что с ними делать (как я показывал выше). Потом редактор закрывается и git пошагово воспроизводит операции (вот как в столбик в редакторе записано).

>pick

>squash

>edit

Ыыыы, какой ужас. Я понимаю, почему перебежчик с Mercurial пишет свой MQ для Git :)

> Полагаю - это и есть mq

В общем, да. Только в mq всё это проще сделано, в стиле quilt.

> + классный гитоплюшки :]

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

> > Тот же ответ - можно менять, можно не менять

> Да, это в стиле Git - назвать rebase операцию, не меняющую base %) 

Она НЕ меняет parent в единственно случае - когда вы хотите только отредактировать коммиты, но не двигать upstream ветку. rebase в общем случае всё равно выдает коллизии, так почему бы их не давать фиксить?(дает), а если давать фиксить, то почему не расширить этот интерфейс для описанных выше операций с коммитами?(расширен) :]

Или вопрос в том, что это слишком ограниченный/неудобный интерфейс?

> В общем, да. Только в mq всё это проще сделано, в стиле quilt. 

Не юзал, но подозреваю, что quilt не знает, что такое система контроля версий и свои патчи там не хранит(тогда он явно гораздо менее удобен ;]), или хранит? Или имеется ввиду интерфейс пользователя? тогда это вообще на вкус и цвет :]

> > + классный гитоплюшки :]

> Список плюшек - в студию, я лично не обнаружил в Git вообще никаких плюшек (если не считать плющкой repack и отсуствие локальных номеров ревизий). Впрочем, я не Линус :)

Ну имелись ввиду различия git rebase с mq, которого я в глаза не видел

Что такое локальные ветки/теги - знаю, что такое локальные ревизии - не знаю :]

> Или вопрос в том, что это слишком ограниченный/неудобный интерфейс?

Именно.

>>> + классный гитоплюшки :]

>> Список плюшек - в студию

>Ну имелись ввиду различия git rebase с mq, которого я в глаза не видел

Жаль, я было подумал, в git есть что-то таакоое...

>> если не считать плющкой repack и отсуствие локальных номеров ревизий

> Что такое локальные ветки/теги - знаю, что такое локальные ревизии - не знаю :]

Что такое локальные ревизии, я тоже не знаю ;)