> Благодаря сжатию без потерь --depth=1 обычно не многим меньше полного репозитория -
> всё равно приходится выкачивать все объекты, общие для присутствующих и отсутствующих
> коммитов, а таких объектов - большинства, со всем оверхедом от них.Эмм... Тут ты меня потерял. Я может недостаточно шарю во внутренностях git? Если по логике вещей: файлы хранятся блобами, так? Несколько блобов могут упаковываться в паки. Но могут и не упаковываться. Если я вынимаю ровно один коммит из ремота, то мне нужны блобы только этого коммита. И... разве git не вынимает из репа только нужные блобы на сервере, чтобы отправить их клиенту? Может быть упаковывая их в пак при этом, но только их. Разве не так? Или сервер отправляет паки в том виде, как они хранятся у него на диске? Или я вообще не о том?
> Бесплатного ланча в сжатии нет, ты либо оптимизируешь под один случай,
> либо под другой. Гит оптимизирован под полные репозитории, что имеет смысл.
> Но в отличие от полного репозитория --depth=1 имеет большие проблемы. Напр.
> хрен сольёшь с ветками, начинающимися от отсутствующего коммита.
Вряд ли ты будешь сливаться с веткой, общий коммит с которой был давным-давным-давно. А если будешь, ничто не мешает тебе получить объекты от точки ветвления и до соответствующих хедов.
> Или метки не получишь.
Это, наверное, можно обойти как-нибудь. Правда я не уверен, что это удастся обойти без скриптописательства. Но в любом случае, прежде чем думать над решением проблемы, надо понять, что за метки тебе нужны. Если тебе нужны все метки, то ведь тебе и вся история тоже нужна, не?
> Геморрой не окупает выигрыш. Поэтому обычно всё тянут целиком.
Потому что обычно размер репа -- не такая большая проблема, как описывает ТС выше.
> Чего гиту не хватает - это возможности перебазировать ветки на другую историю.
> Чтобы апстрим мог начать историю сначала, выкинув все коммиты, а всю
> информацию об авторстве с гранулярностью по строкам записав в специальный блоб.
Это можно скриптом сделать. Он правда выполняться будет хренову тучу времени... По-крайней мере, если делать "в лоб". Но если теоретически, ты можешь составить список всех строк проекта, составить список авторов, после чего сопоставить каждой строке автора. Потом идёшь на самое начало истории, создаёшь там ветку, и затем ребазишь туда master, в процессе разбивая его на N коммитов по количеству авторов. В каждый такой коммит суёшь только строки одного автора и так по всем авторам.
Или можно даже проще. Делаешь rebase master'а в пустую ветку, сортируешь все коммиты по автору, после чего по каждому автору squash всех коммитов. Можно потом результат почистить, выкинув оттуда "нулевые" коммиты, которые ничего не меняют. Хотя не, если один человек добавил строчку, а другой её изменил, то при таком подходе эта строчка будет дважды записана. Не, так не выйдет. История станет короче, но это не значит, что меньше.
