[devel] Бранч для svn-репозитария в git
Eugene Prokopiev
=?iso-8859-1?q?enp_=CE=C1_altlinux=2Eorg?=
Пн Сен 1 12:34:17 MSD 2008
01.09.08, Alexey I. Froloff<raorn@> написал(а):
> * Eugene Prokopiev <enp@> [080831 23:48]:
>
> > У меня тоже tar делался из ремотного бранча, но после push на
> > git.alt и clone оттуда этот ремотный бранч уже не был виден -
> > т.о. разработчик, сделавший clone, не мог просто сделать
> > git-svn fetch для обновления апстримных исходников, а должен
> > был сделать перед тем git-svn init. В вашем случае это тоже
> > так?
>
> Почти. В моём примере их надо тоже пушить явно:
>
> 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 и в клонированном репозитарии ремотных бранчей не видно
> Правая сторона может быть и не refs/remotes/*, а refs/svn/*.
$ ls .git/refs/svn*
ls: .git/refs/svn*: No such file or directory
> Но чтобы работал git svn, локально эти ветки должны быть в
> refs/remotes/. Хотя по слухам это можно и настроить через
> .git/config, но я это пока не очень асилил.
спасибо, погляжу
> Чтобы второй разработчик мог делать git svn fetch надо либо
> скопировать кусок .git/config относящийся к svn у первого
> разработчика или сделать git svn init и расставить нужные бранчи
> в том виде как их ожидает найти git svn.
зачем тогда делать git push origin ... ?
по моим наблюдениям как раз git svn init или редактирования
.git/config достаточно - получается это вполне кошерный способ?
> > Меня именно модель взаимодействия больше всего интересует - я выпускаю
> > одну версию, другой разработчик - следующую, потом выпускаю еще раз я.
>
> $ git remote add РАЗРАБОТЧИК git.alt:/people/РАЗРАБОТЧИК/packages/ПАКЕТ.git
> $ git fetch РАЗРАБОТЧИК
это я делаю после того, как второй разработчик клонировал репозитарий,
создал свой бранч на основе моего srpms, чего-то там сделал, а я хочу
это увидеть и, возможно, смержить?
> Я ещё делаю
>
> $ git fetch РАЗРАБОТЧИК 'refs/heads/*:refs/heads/*'
можно популярно объяснить, зачем это надо?
> Если накоммитили в одно время, fast-forward не будет и некоторые
> ветки придётся мержить явно.
а бывает и неявно? можно об этом подробнее?
> Ну и синхронизировать периодически между собой.
я не очень понял, а упомянутые неявные мержи не относятся к процессу
взаимодействия между разработчиками?
> Два разработчика + SVN есть в ruby.git у меня и kas.
это хорошо, когда есть пример :)
--
С уважением,
Прокопьев Евгений
Подробная информация о списке рассылки Devel