[devel] git submodules on git.alt

[devel] git submodules on git.alt

[Max Ivanov]

How to deal with git submodules? Upstream uses them in some places and
I don't know how to put their content in the final source tree prior
to %build stage. Is it even possible?

Re: [devel] git submodules on git.alt

[Alexey Gladkov]

On 09.01.2010 23:19, Max Ivanov wrote:
> How to deal with git submodules? Upstream uses them in some places and
> I don't know how to put their content in the final source tree prior
> to %build stage. Is it even possible?

I did support for submodules, but gear's upstream don't want it.

http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/submodule

-- 
Rgrds, legion

Re: [devel] git submodules on git.alt

[Michael Shigorin]

On Sat, Jan 09, 2010 at 11:29:41PM +0300, Alexey Gladkov wrote:
> I did support for submodules, but gear's upstream don't want it.

Did they call it names or have they actually explained the reason?

(послали или объяснили?)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] git submodules on git.alt

[Alexey Gladkov]

On 09.01.2010 23:53, Michael Shigorin wrote:
> On Sat, Jan 09, 2010 at 11:29:41PM +0300, Alexey Gladkov wrote:
>> I did support for submodules, but gear's upstream don't want it.
> 
> Did they call it names or have they actually explained the reason?

Reason: wrong ideology.

I completely disagree with it.

-- 
Rgrds, legion

Re: [devel] git submodules on git.alt

[Michael Shigorin]

On Sun, Jan 10, 2010 at 12:29:38AM +0300, Alexey Gladkov wrote:
> >> I did support for submodules, but gear's upstream don't want it.
> > Did they call it names or have they actually explained the reason?
> Reason: wrong ideology.  I completely disagree with it.

It requires The Right ideology to be described.

Если имеет место указание на неверную идеологию,
верная должна быть описана.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] git submodules on git.alt

[Max Ivanov]

>
> It requires The Right ideology to be described.

Right! Using git submodules isn't my decision, I have nothing to do
with it, support of submodules should exist in current tools or there
is should be a proper and convinient workaround.

Re: [devel] git submodules vs gear

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

On Sat, Jan 09, 2010 at 11:29:41PM +0300, Alexey Gladkov wrote:
> On 09.01.2010 23:19, Max Ivanov wrote:
> > How to deal with git submodules? Upstream uses them in some places and
> > I don't know how to put their content in the final source tree prior
> > to %build stage. Is it even possible?
> 
> I did support for submodules, but gear's upstream don't want it.
> 
> http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/submodule

The main idea behind GIT submodule is that it allows weak references.
These objects (gitlink tree entries) refer to commit objects which are
allowed to be missing from the git repository.  Regular git tools like
git-fetch, git-push and their derivatives do not follow such references.
To complete a full git checkout for a tree containing submodules,
additional commands (e.g. "git submodule update") need to be executed
to fetch required commit objects from external git repositories.

For example, GNU coreutils project uses gnulib submodule:
http://git.savannah.gnu.org/cgit/coreutils.git/plain/.gitmodules

The main idea behind gear is to reproducibly extract archive from a
given git repository.  gear (in its basic form) takes a git repository,
a commit id, and outputs a tarball.  Every commit object referenced by
the given commit id must be extractable from the given git repository.
Now imagine that this commit id uses submodules and required external
commit objects are missing, because no git repository that uses
submodules is required to be self-contained.  In this case, gear would
have to attempt to fetch these commits from internet.  This is NOT
reliable, and gear would not be able to guarantee reproducibly.

As you see, there is a fundamental problem: GIT submodule breaks
repository completeness, but gear requires git repositories to be
self-contained.  I have no idea how to avoid this problem.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules on git.alt

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

On Sat, Jan 09, 2010 at 11:34:24PM +0200, Michael Shigorin wrote:
> > >> I did support for submodules, but gear's upstream don't want it.
> > > Did they call it names or have they actually explained the reason?
> > Reason: wrong ideology.  I completely disagree with it.
> It requires The Right ideology to be described.
Single sha1-id must be enough to fetch all required objects from
a single git repository in order to create same pkg.tar for a
given sha1-id.

Build tag points to tree-ish, tree-ish contains .gear/rules and
.gear/tags/*, .gear/tags/* contains pointers to other tree-ishs.
Fetching single build tag must also fetch all these objects from
a single repository.

-- 
Regards,    --
Sir Raorn.   --- http://thousandsofhate.blogspot.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules vs gear

[Max Ivanov]

> As you see, there is a fundamental problem: GIT submodule breaks
> repository completeness, but gear requires git repositories to be
> self-contained.  I have no idea how to avoid this problem.

Is there any way to fetch required commits and push it to git.alt as
complete separate branch without any common history? Then all
nessesary commits will exist in one git repo.

Re: [devel] git submodules on git.alt

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Sat, Jan 09, 2010 at 08:19:09PM +0000, Max Ivanov wrote:
> How to deal with git submodules? Upstream uses them in some places and
> I don't know how to put their content in the final source tree prior
> to %build stage. Is it even possible?

Due to the fundamental problem already described in this thread, you
cannot use git submodules AS IS to build packages using gear.  There is
simple workaround you can use to overcome this problem:
1. Extract each submodule into separate tarball using appropriate
   .gear/rules; this is trivial because you know commit ids.
2. Make sure that your build commit inherits to all these submodule
   commits.

Unfortunately, there are no means in gear-update-*whatever* yet to
automate this work.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules vs gear

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

On Sat, Jan 09, 2010 at 10:36:51PM +0000, Max Ivanov wrote:
> > As you see, there is a fundamental problem: GIT submodule breaks
> > repository completeness, but gear requires git repositories to be
> > self-contained.  I have no idea how to avoid this problem.
> 
> Is there any way to fetch required commits and push it to git.alt as
> complete separate branch without any common history? Then all
> nessesary commits will exist in one git repo.

To ensure that a given build tag is self-contained, all commit objects
that are required for build must be among build tag's predecessors.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules on git.alt

[Alexey Gladkov]

On 10.01.2010 00:34, Michael Shigorin wrote:
> It requires The Right ideology to be described.
> 
> Если имеет место указание на неверную идеологию,
> верная должна быть описана.

Прочитай это:

https://bugzilla.altlinux.org/show_bug.cgi?id=17914

-- 
Rgrds, legion

Re: [devel] git submodules vs gear

[Anton Farygin]

10.01.2010 01:31, Dmitry V. Levin пишет:
> On Sat, Jan 09, 2010 at 11:29:41PM +0300, Alexey Gladkov wrote:
>> On 09.01.2010 23:19, Max Ivanov wrote:
>>> How to deal with git submodules? Upstream uses them in some places and
>>> I don't know how to put their content in the final source tree prior
>>> to %build stage. Is it even possible?
>>
>> I did support for submodules, but gear's upstream don't want it.
>>
>> http://git.altlinux.org/people/legion/packages/gear.git?p=gear.git;a=shortlog;h=refs/heads/submodule

<skip>

>
> As you see, there is a fundamental problem: GIT submodule breaks
> repository completeness, but gear requires git repositories to be
> self-contained.  I have no idea how to avoid this problem.

Более того - в git появился git fetch --depth , который тоже ломает 
целостность репозитория.

Но было бы неплохо научиться с ним жить.

С submodules я столкнулся с такими проблемами, что мне оказалось проще 
импортировать tar.bz, чем тащить submodules в отдельные бранчи, а потом 
всё это мержить с ours.

Особенно, когда в виде submodule используется git ядра.

Re: [devel] git submodules on git.alt

[Anton Farygin]

10.01.2010 01:43, Dmitry V. Levin пишет:
> On Sat, Jan 09, 2010 at 08:19:09PM +0000, Max Ivanov wrote:
>> How to deal with git submodules? Upstream uses them in some places and
>> I don't know how to put their content in the final source tree prior
>> to %build stage. Is it even possible?
>
> Due to the fundamental problem already described in this thread, you
> cannot use git submodules AS IS to build packages using gear.  There is
> simple workaround you can use to overcome this problem:
> 1. Extract each submodule into separate tarball using appropriate
>     .gear/rules; this is trivial because you know commit ids.
> 2. Make sure that your build commit inherits to all these submodule
>     commits.
>
> Unfortunately, there are no means in gear-update-*whatever* yet to
> automate this work.


Это хороший метод, но он зачастую неудобен - git репозиторий вырастает 
до непотребных размеров (700Mb, для примера), получающийся из суммы всех 
submodules.

git fetch --depth помог бы, но такие репозитории у меня не получилось 
выложить на git.alt.

Re: [devel] git submodules vs gear

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

On Sun, Jan 10, 2010 at 11:45:27AM +0300, Anton Farygin wrote:
[...]
> Более того - в git появился git fetch --depth , 
> который тоже ломает целостность 
> репозитория.

Нет, git fetch --depth ломает целостность только того репозитория, в
котором выполняется, и результат не удастся запушить дальше.

> Но было бы неплохо научиться с ним жить.

С этим (оно ещё называется shallow clone) я никаких проблем не вижу.

> С submodules я столкнулся с такими проблемами, 
> что мне оказалось проще импортировать 
> tar.bz, чем тащить submodules в отдельные бранчи, 
> а потом всё это мержить с ours.

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules vs gear

[Michael Shigorin]

On Sun, Jan 10, 2010 at 01:31:25AM +0300, Dmitry V. Levin wrote:
> Now imagine that this commit id uses submodules and required external
> commit objects are missing, because no git repository that uses
> submodules is required to be self-contained.  In this case, gear would
> have to attempt to fetch these commits from internet.  This is NOT
> reliable, and gear would not be able to guarantee reproducibly.

Цитируя https://bugzilla.altlinux.org/show_bug.cgi?id=17914#c24:
> Привнесение поддержки submodule не должно сломать эту гарантию.

Не можешь дать гарантию -- не давай.  Особенно если опираешься на
услуги посредников. git когда-то давно мог гарантировать _полную_
историю, а потом появились shallow clones и submodules (причём не
от прихоти или "разработки ради разработки") и эта гарантия стала
ограниченной.  Собственно, что legion@ и говорит в #c45.

Цитируя #c26 и #c34:
> Нарушается принцип достаточности коммита.

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

А ключевые принципы, на которые опираются hasher, gear и подобные
инструменты -- неплохо было б описывать в их документации.

Пока что отсутствие поддержки git submodule в сизифном gear
противоречит его же документированной идее ("собирать пакеты
из произвольно устроенного git-репозитория") и описанным
ограничениям, накладываемым на структуру репозитория.

При этом упомянутый тобой принцип в ABOUT.ru.utf8 не описан --
вскользь проскакивает во фразе "согласно которым производится
экспорт из коммита репозитория (в форму, из которой можно
однозначно изготовить srpm-пакет или запустить сборку)" разве.

То есть твоя позиция нарушает явно сформулированный принцип,
даже если, как выясняется в баге с патчем, опирается на другой
-- нигде не опубликованный до обсуждения в баге, как понимаю.

> As you see, there is a fundamental problem: GIT submodule breaks
> repository completeness, but gear requires git repositories to be
> self-contained.  I have no idea how to avoid this problem.

Исправить ожидания gear на соответствующие наблюдаемой
действительности, разумеется.

Возможно, обязав заливать используемые для субмодулей репо на
git.alt и указывать соответствие где-нить в .gear/submodules
во избежание тупой автоматической траты времени и трафика.

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] git submodules vs gear

[Anton Farygin]

10.01.2010 19:05, Dmitry V. Levin пишет:
> On Sun, Jan 10, 2010 at 11:45:27AM +0300, Anton Farygin wrote:
> [...]
>> Более того - в git появился git fetch --depth ,
>> который тоже ломает целостность
>> репозитория.
>
> Нет, git fetch --depth ломает целостность только того репозитория, в
> котором выполняется, и результат не удастся запушить дальше.
>
>> Но было бы неплохо научиться с ним жить.
>
> С этим (оно ещё называется shallow clone) я никаких проблем не вижу.

Отлично. Кстати, а ты уже реализовал, что бы такие репозитоии можно было 
пушить на git.alt ?

>
>> С submodules я столкнулся с такими проблемами,
>> что мне оказалось проще импортировать
>> tar.bz, чем тащить submodules в отдельные бранчи,
>> а потом всё это мержить с ours.
>
> Нужен инструмент, который бы автоматически находил и мержил все
> используемые для сборки submodules.

Да, и автоматически прописывал правила в .gear/rules, правил спек 
(добавлял тарболлы) и тэги.

Впрочем, как раз эта работа не сильно напрягает. У меня есть более 
странный случай, когда в локальном репозитории, сделанным таким образом, 
  submodule указывает в несуществующее у upstream место.

Как я этого добился - не знаю, желающие могут поиграться с kvm-kmod.git 
(взять в upstream и попробовать реализовать схему с submodules в 
отдельных бранчах).

Точнее говоря - это наш старый git.alt kvm'а, при обновлении до свежих 
версий kvm-kmod, kvm-kernel и qemu-kvm вылезает такая проблема.

Re: [devel] git submodules vs gear

[Anton Farygin]

10.01.2010 20:46, Michael Shigorin пишет:
> On Sun, Jan 10, 2010 at 01:31:25AM +0300, Dmitry V. Levin wrote:
>> Now imagine that this commit id uses submodules and required external
>> commit objects are missing, because no git repository that uses
>> submodules is required to be self-contained.  In this case, gear would
>> have to attempt to fetch these commits from internet.  This is NOT
>> reliable, and gear would not be able to guarantee reproducibly.
>
> Цитируя https://bugzilla.altlinux.org/show_bug.cgi?id=17914#c24:
>> Привнесение поддержки submodule не должно сломать эту гарантию.
>
> Не можешь дать гарантию -- не давай.  Особенно если опираешься на
> услуги посредников. git когда-то давно мог гарантировать _полную_
> историю, а потом появились shallow clones и submodules (причём не
> от прихоти или "разработки ради разработки") и эта гарантия стала
> ограниченной.  Собственно, что legion@ и говорит в #c45.

submodules вообще ужасен - трафик вырастает даже не на порядок.

Вообще, git очень расточителен к трафику при клонировании, а submodules 
заставляет это делать при каждой сборке.

Вот я представил себе, что у меня в submodules сидит ядро, и при каждом 
gear-hsh оно клонируется, так мне стало плоховато... ;(

Re: [devel] git submodules vs gear

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

On Sun, Jan 10, 2010 at 10:07:54PM +0300, Anton Farygin wrote:
> 10.01.2010 19:05, Dmitry V. Levin пишет:
> >On Sun, Jan 10, 2010 at 11:45:27AM +0300, Anton Farygin wrote:
> >[...]
> >>Более того - в git появился git fetch --depth ,
> >>который тоже ломает целостность
> >>репозитория.
> >
> >Нет, git fetch --depth ломает целостность только 
> >того репозитория, в
> >котором выполняется, и результат не 
> >удастся запушить дальше.
> >
> >>Но было бы неплохо научиться с ним жить.
> >
> >С этим (оно ещё называется shallow clone) я 
> >никаких проблем не вижу.
> 
> Отлично. Кстати, а ты уже реализовал, что 
> бы такие репозитоии можно было пушить на 
> git.alt ?

Нет, на git.alt репозитории должны быть целостные, иначе с ними будет
очень неудобно работать (несмотря на то, что gear с ними работает).
Непонятно, как это лучше реализовать.  Возможно, нужен какой-то
server side fetch.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules vs gear

[Anton Farygin]

10.01.2010 22:46, Dmitry V. Levin пишет:
> On Sun, Jan 10, 2010 at 10:07:54PM +0300, Anton Farygin wrote:
>> 10.01.2010 19:05, Dmitry V. Levin пишет:
>>> On Sun, Jan 10, 2010 at 11:45:27AM +0300, Anton Farygin wrote:
>>> [...]
>>>> Более того - в git появился git fetch --depth ,
>>>> который тоже ломает целостность
>>>> репозитория.
>>>
>>> Нет, git fetch --depth ломает целостность только
>>> того репозитория, в
>>> котором выполняется, и результат не
>>> удастся запушить дальше.
>>>
>>>> Но было бы неплохо научиться с ним жить.
>>>
>>> С этим (оно ещё называется shallow clone) я
>>> никаких проблем не вижу.
>>
>> Отлично. Кстати, а ты уже реализовал, что
>> бы такие репозитоии можно было пушить на
>> git.alt ?
>
> Нет, на git.alt репозитории должны быть целостные, иначе с ними будет
> очень неудобно работать (несмотря на то, что gear с ними работает).
> Непонятно, как это лучше реализовать.  Возможно, нужен какой-то
> server side fetch.

Я не совсем понял, что ты имеешь в виду под server side fetch ?

Если gear при сборке будет ходить куда-то на сторону, то это по сути 
очень похоже на submodules.

Кстати, было бы неплохо научить (если не умеет) git submodules качать 
именно таким образом - только один нужный коммит, а не всю историю 
изменений.

Re: [devel] git submodules vs gear

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 3745 bytes --]

On Sun, Jan 10, 2010 at 07:46:41PM +0200, Michael Shigorin wrote:
> On Sun, Jan 10, 2010 at 01:31:25AM +0300, Dmitry V. Levin wrote:
> > Now imagine that this commit id uses submodules and required external
> > commit objects are missing, because no git repository that uses
> > submodules is required to be self-contained.  In this case, gear would
> > have to attempt to fetch these commits from internet.  This is NOT
> > reliable, and gear would not be able to guarantee reproducibly.
> 
> Цитируя https://bugzilla.altlinux.org/show_bug.cgi?id=17914#c24:
> > Привнесение поддержки submodule не должно сломать эту гарантию.
> 
> Не можешь дать гарантию -- не давай.

Мне нужно, чтобы пакет воспроизводимо собирался на изолированном от
внешнего мира сервере.  Если инструмент не даёт мне такой гарантии,
то мне такой инструмент не нужен.

> Особенно если опираешься на
> услуги посредников. git когда-то давно мог гарантировать _полную_
> историю, а потом появились shallow clones и submodules (причём не
> от прихоти или "разработки ради разработки") и эта гарантия стала
> ограниченной.  Собственно, что legion@ и говорит в #c45.

shallow clones и submodules не нарушают главного свойства git -- гарантии
неизменности истории.  А то, что часть коммитов может быть оформлена таким
образом, чтобы снять обязательность локального размещения -- это не меняет
сути дела для git.  Всё таки надо понимать, что у git и gear разные
задачи.

> Цитируя #c26 и #c34:
> > Нарушается принцип достаточности коммита.
> 
> Ну и что?  Не можешь решить проблему за человека -- не мешай ему
> самому решать их, создавая непреодолимые.  "Не навреди".
> 
> А ключевые принципы, на которые опираются hasher, gear и подобные
> инструменты -- неплохо было б описывать в их документации.

Я стараюсь в меру своих сил и возможностей.

> Пока что отсутствие поддержки git submodule в сизифном gear
> противоречит его же документированной идее ("собирать пакеты
> из произвольно устроенного git-репозитория") и описанным
> ограничениям, накладываемым на структуру репозитория.

Когда был написан этот текст, git submodule не было даже в проекте.
Очевидно, текст требуется актуализировать.

> При этом упомянутый тобой принцип в ABOUT.ru.utf8 не описан --
> вскользь проскакивает во фразе "согласно которым производится
> экспорт из коммита репозитория (в форму, из которой можно
> однозначно изготовить srpm-пакет или запустить сборку)" разве.
> 
> То есть твоя позиция нарушает явно сформулированный принцип,
> даже если, как выясняется в баге с патчем, опирается на другой
> -- нигде не опубликованный до обсуждения в баге, как понимаю.

Очевидно, формулировки пора обновить, чтобы они лучше отражали реальную
картину.

> > As you see, there is a fundamental problem: GIT submodule breaks
> > repository completeness, but gear requires git repositories to be
> > self-contained.  I have no idea how to avoid this problem.
> 
> Исправить ожидания gear на соответствующие наблюдаемой
> действительности, разумеется.

Повторю ещё раз: мне нужно, чтобы gear решал вполне простую и понятную
задачу (я написал выше, какую).
> 
> Возможно, обязав заливать используемые для субмодулей репо на
> git.alt

Это не представляется возможным.

> и указывать соответствие где-нить в .gear/submodules
> во избежание тупой автоматической траты времени и трафика.
> 
> При этом технический мерж можно делать прямо перед скручиванием
> тарбола, как понимаю.  И репо чистые, и Дима доволен.

Сборочный тэг должен указывать на коммит, замыкание которого находится
в репозитории целиком и передаётся базовыми операциями (git fetch и
git push) без потерь.  Всё остальное -- детали реализации.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules vs gear

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

On Sun, Jan 10, 2010 at 10:59:16PM +0300, Anton Farygin wrote:
> 10.01.2010 22:46, Dmitry V. Levin пишет:
[...]
> >Нет, на git.alt репозитории должны быть 
> >целостные, иначе с ними будет
> >очень неудобно работать (несмотря на то, 
> >что gear с ними работает).
> >Непонятно, как это лучше реализовать.  
> >Возможно, нужен какой-то
> >server side fetch.
> 
> Я не совсем понял, что ты имеешь в виду 
> под server side fetch ?

Поясню на примере.  У меня есть coreutils.git, который, как известно,
использует gnulib (и ссылается на конкретный коммит из gnulib через
gitlink).  Было бы удобно, если бы я мог выполнить что-нибудь вроде
ssh git.alt fetch packages/coreutils
в результате чего в git.alt:packages/coreutils.git оказались бы свежие
коммиты из подпроекта gnulib, тогда мне не пришлось бы закачивать их со
своего хоста на git.alt.

Непонятно только, как это удобство реализовать.  Ведь я знаю, откуда
обновить gnulib, об этом даже в v8.3:.gitmodules написано, но откуда это
узнает сервер git.alt?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules vs gear

[Anton Farygin]

10.01.2010 23:08, Dmitry V. Levin пишет:
> On Sun, Jan 10, 2010 at 10:59:16PM +0300, Anton Farygin wrote:
>> 10.01.2010 22:46, Dmitry V. Levin пишет:
> [...]
>>> Нет, на git.alt репозитории должны быть
>>> целостные, иначе с ними будет
>>> очень неудобно работать (несмотря на то,
>>> что gear с ними работает).
>>> Непонятно, как это лучше реализовать.
>>> Возможно, нужен какой-то
>>> server side fetch.
>>
>> Я не совсем понял, что ты имеешь в виду
>> под server side fetch ?
>
> Поясню на примере.  У меня есть coreutils.git, который, как известно,
> использует gnulib (и ссылается на конкретный коммит из gnulib через
> gitlink).  Было бы удобно, если бы я мог выполнить что-нибудь вроде
> ssh git.alt fetch packages/coreutils
> в результате чего в git.alt:packages/coreutils.git оказались бы свежие
> коммиты из подпроекта gnulib, тогда мне не пришлось бы закачивать их со
> своего хоста на git.alt.
>
> Непонятно только, как это удобство реализовать.  Ведь я знаю, откуда
> обновить gnulib, об этом даже в v8.3:.gitmodules написано, но откуда это
> узнает сервер git.alt?

Я не вижу в этом функционале большой пользы, пока не появится 
возможность сказать ssh git.alt test-build.

Т.е. - до тех пор, пока мы не сможем реализовать полный цикл сборки 
пакета, минуя хост мейнтейнера.

Иначе мне в любом случае придётся выкачивать большие репозитории 
локально, хотя бы что бы попробовать.

Не знаю, у кого как, но у меня скорость на upload значительно выше, чем 
на download. соответственно если я к себе что-то скачал, то выложить это 
- не проблема.

Проблема скачать - пять центов за мегабайт пока никто не отменял.

Re: [devel] git submodules vs gear

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On Mon, Jan 11, 2010 at 12:13:48PM +0300, Anton Farygin wrote:

AF> Не знаю, у кого как, но у меня скорость на upload значительно выше, чем 
AF> на download. соответственно если я к себе что-то скачал, то выложить это 
AF> - не проблема.
AF> Проблема скачать - пять центов за мегабайт пока никто не отменял.

В Москве большинство операторов дают почему-то узкий upload. Ну и ADSL еще
никто не отменял.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules vs gear

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Sun, Jan 10, 2010 at 10:07:54PM +0300, Anton Farygin wrote:
[...]
> Впрочем, как раз эта работа не сильно 
> напрягает. У меня есть более странный 
> случай, когда в локальном репозитории, 
> сделанным таким образом, submodule указывает 
>  в несуществующее у upstream место.

upstream не может гарантировать неизменность репозитория.
Да, это обратная сторона медали, потому gitlink и называют
слабыми ссылками, что они не гарантируют связности.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git submodules vs gear

[REAL]

Денис Смирнов пишет:
> В Москве большинство операторов дают почему-то узкий upload. Ну и ADSL еще
> никто не отменял.

Я вот из дома вооще могу часами делать git push (в отличие от git 
remote update, который на несколько порядков быстрее). Буквально 
десять килобайт в минуту... Но у меня gprs. С работы, где нормальная 
живая сетка, git push проходит довольно быстро, тут только git svn 
fetch как корова с простреленными ногами...

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] git submodules vs gear

[Anton Farygin]

11.01.2010 23:56, Dmitry V. Levin пишет:
> On Sun, Jan 10, 2010 at 10:07:54PM +0300, Anton Farygin wrote:
> [...]
>> Впрочем, как раз эта работа не сильно
>> напрягает. У меня есть более странный
>> случай, когда в локальном репозитории,
>> сделанным таким образом, submodule указывает
>>   в несуществующее у upstream место.
>
> upstream не может гарантировать неизменность репозитория.
> Да, это обратная сторона медали, потому gitlink и называют
> слабыми ссылками, что они не гарантируют связности.

Нет, я говорю действительно странный случай, когда содержимое одного и 
того-же коммита, изменяющего submodule, отличается у меня и в upstream.