LINUX.ORG.RU

Не выкачивать всю историю изменений git-ом

 ,


0

2

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

Может ли git работать с хранилищем, не выкачивая всю историю изменений для всех файлов? Как это правильно называется, чтобы найти в мануалах?

★★★★★

git clone –depth=1 … ?

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

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 2)
Ответ на: комментарий от gtk3

Этот ваш гитхаб умеет работать с svn-клиентами, а он уже может частично чекаутить. В отличие от этого вашего гита.

Для справки: git тоже умеет частично чекаутить. Но речь тут не про это.

yvv ★★☆ ()
Ответ на: комментарий от yvv

Для справки: git тоже умеет частично чекаутить. Но речь тут не про это.

Смысл частичного чекаута в том чтобы не выкачивать из сети все д..мо из репозитория, а скачать только нужное. Особенно если у тебя ADSL (хорошо что не dial-up). А эта штука, как я понял, клонирует всё целиком и всего лишь частично извлекает нужные файлы в рабочий каталог. Только толку от этого?

gtk3 ★★★ ()
Ответ на: комментарий от den73

Например:

svn export https://github.com/nzeemin/nzeemin-opensrc/trunk/dingoo/ColorLinesSdl/src ColorLinesSdl
cd ColorLinesSdl
gcc `sdl-config --cflags --libs` main.c -o Lines
./Lines

Из этого репозитория с кучей исходников: https://github.com/nzeemin/nzeemin-opensrc/

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от yvv

Если git clone –depth=1, то это sparse checkout позволит скачать «четверть коммита»? Сомневаюсь, выше уже ответили что никак, что это лишь часть данных из индекса вывалит - приятно, но если файл 10 гигабайт и 100 мегабайт кода, то скачается 11.1 гигабайт (если без сжатия)

Но что если для тяжелых «ресурсов» отдельная репа, git позволит её пропустить? В одной конторе наблюдал как много отдельных репов были, но сливались в один каталог. Да собственно и некоторые открытые проекты такое используют

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)

на всякий случай - есть ещё git lfs, правда, когда мы им пользовались, он нам очень не понравился - глючил. Но это должно быть в самом репозитории настроено. Не знаю, может, его уже закопали.

den73 ★★★★★ ()

Качай по прямым ссылкам и заливай через веб-интерфейс гитхаба :)

где много сотен бинарных артефактов десятки мегабайт каждый

Для артефактов есть релизы. Зачем их в реп добавлять?

KillTheCat ★★★★★ ()

Есть репа на Гитхабе, где много сотен бинарных артефактов десятки мегабайт каждый

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

byko3y ★★★ ()
Ответ на: комментарий от yvv

Ну заведи. Кто тебе мешает?

Наличие замечательных утилит rsync, diff, patch, которые удобнее, чем система реп из одного файла. Хотя, у этого набора утилит есть более известное название:

«RCS operates only on single files. It has no way of working with an entire project, so it does not support atomic commits affecting multiple files»

byko3y ★★★ ()
Ответ на: комментарий от Crocodoom

Потому что может

Потому что хостинг

У гитхаба ни разу не резиновый хостинг, потому достаточно большие бинарники гонять туда-сюда не получится. У того же Helix SVN хостинг имеет примерно те же ограничения на закрытые репы (1 Гб репа, 5 пользователей), что и GitHub (1 Гб, 3 пользователя). То, что хостингов SVN мало, не значит, что их нет. SVN никуда не уходит, потому что Git не может его заменить полностью. Меньше спрос — меньше предложение, вот и вся история. Хотя, конечно, лучше всего SVN сияет в централизованной разработке на корпоративном серваке.

byko3y ★★★ ()