[devel] Бранч для svn-репозитария в git

[Alexey I. Froloff]

* Eugene Prokopiev <enp@> [080901 12:35]:
> >  git push origin refs/remotes/trunk:refs/remotes/trunk
> >  git push origin 'refs/remotes/tags/*:refs/remotes/tags/*'
> >  git push origin 'refs/remotes/branches/*:refs/remotes/branches/*'
> сделал, но на git.alt и в клонированном репозитарии ремотных бранчей не видно
А git.alt на это как-то ругнулся?  Я честно говоря не пробовал
так делать, но обработку remotes в girar краем глаза видел ;-)

> >  Правая сторона может быть и не refs/remotes/*, а refs/svn/*.
> $ ls .git/refs/svn*
> ls: .git/refs/svn*: No such file or directory
Правая сторона:

$ git push origin refs/remotes/trunk:refs/svn/trunk
$ git push origin 'refs/remotes/tags/*:refs/svn/tags/*'
$ git push origin 'refs/remotes/branches/*:refs/svn/branches/*'

> >  Чтобы второй разработчик мог делать git svn fetch надо либо
> >  скопировать кусок .git/config относящийся к svn у первого
> >  разработчика или сделать git svn init и расставить нужные бранчи
> >  в том виде как их ожидает найти git svn.
> зачем тогда делать git push origin ... ?
Чтобы туда попали head'ы нужных веток и коммиты.

> по моим наблюдениям как раз git svn init или редактирования
> .git/config достаточно - получается это вполне кошерный способ?
Я это делал один раз, при чём у меня валялся какой-то тухлый
.git/svn/ от предыдужих экспериментов.  Очень вероятно, что
что-то в моих действиях git сделает автоматом.  В какой-то момент
он начал вывасывать все ревизии начиная с первой, новые об'екты
при этом не создавались, просто remotes/trunk перемещался по
дереву.  Не помню, было ли это до удаления старого .git/svn/ или
между удалением и созданием нужных бранчей.

> > $ git remote add РАЗРАБОТЧИК git.alt:/people/РАЗРАБОТЧИК/packages/ПАКЕТ.git
> >  $ git fetch РАЗРАБОТЧИК
> это я делаю после того, как второй разработчик клонировал репозитарий,
> создал свой бранч на основе моего srpms, чего-то там сделал, а я хочу
> это увидеть и, возможно, смержить?
Да.  Создадутся ветки remotes/РАЗРАБОТЧИК/*.

> >  $ git fetch РАЗРАБОТЧИК 'refs/heads/*:refs/heads/*'
> можно популярно объяснить, зачем это надо?
Чтобы не делать один-два-десять раз

$ git checkout branch
$ git pull . РАЗРАБОТЧИК/branch (или git pull РАЗРАБОТЧИК branch)

Но работает это только для fast-forward.

> >  Если накоммитили в одно время, fast-forward не будет и некоторые
> >  ветки придётся мержить явно.
> а бывает и неявно? можно об этом подробнее?
Чуть выше написано.  В ruby есть svn, ветка up, куда мержится
svn/branches/ruby1_8_7, ветки с патчами и всё смержено в итоге в
master.  Кирилл зарелизил 1.8.7-alt6, потом я сделал один коммит
в master (исправления для ppc).  Дальше Кирилл втягивает этот мой
коммит в master и продолжает разработку.

Если он сразу проверит, не коммитил ли я чего, история будет
линейной, его коммит, мой, потом опять его.  Если забудет, то
fetch 'refs/heads/*:refs/heads/*' ругнётся что fast-forward
невозможен и придётся делать pull raorn master.

Нас пока двое, пакет не очень динамично развивается, поэтому
topic-веток мы не плодим, сильно экспериментами не занимаемся.
Получается как будто в разное время коммитим в один и тот же
репозитарий.

> >  Ну и синхронизировать периодически между собой.
> я не очень понял, а упомянутые неявные мержи не относятся к процессу
> взаимодействия между разработчиками?
"Неявные мержи" это fast-forward.  Есть простой способ (начиная с
git 1.5.0, IIRC) попытаться сделать его для нескольких веток
сразу.

-- 
Regards,
Sir Raorn.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20080901/d380db87/attachment-0002.bin>