[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