[devel] git-fetch : not updating to non-fast forward branch
Eugene Prokopiev
=?iso-8859-1?q?prokopiev_=CE=C1_stc=2Edonpac=2Eru?=
Сб Июн 9 14:48:17 MSD 2007
Kirill A. Shutemov пишет:
> On [Sat, 09.06.2007 13:17], Eugene Prokopiev wrote:
>
>>Kirill A. Shutemov пишет:
>>
>>>On [Sat, 09.06.2007 09:13], Eugene Prokopiev wrote:
>>>
>>>
>>>>И правда, ссылка refs/heads/dbmail_2_2 в моем репозитарии осталась
>>>>прежней. Кто виноват и что делать?
>>>
>>>
>>>Ещё одно решение git fetch -f ... Насильно заберёт то что ему сказали,
>>>возможно затерев часть локальнои истории.
>>
>>Да, забрал, но среди новых коммитов нет ничего похожего на релиз 2.2.5,
>>только rc3 и исправления после него :(
>>
>>Я уже раскаиваюсь в том, что в своих пакетах связался с апстримными
>>git/svn, проблем намного больше, чем пользы. Думаю, не перейти ли мне на
>>тарболлы ;) В связи с чем вопрос: а чем лучше хранение в git
>>распакованного тарболла с исходниками, чем запакованного, если обновлять
>>его содержимое я буду с помощью git-rm/git-add?
>
>
> Если будете хранить запакованный тарболл в git'е, то каждое изменение
> тарболла повлечёт за собой появление в git'овской базе одного, но очень
> большого объекта. Следовательно, больший репозиторий, больше трафика +
> неинформативный git diff.
А разве в случае git-rm/git-add трафика будет меньше? Или в этом случае
git умудряется передавать только изменения?
А неинформативным git будет в любом случае (что там поймешь, особенно
если git и правда будет передавать изменения), но эта информация в
отрыве от апстримного git/svn никакой ценности не представляет.
--
С уважением, Прокопьев Евгений
Подробная информация о списке рассылки Devel