LINUX.ORG.RU

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

 ,


0

2

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

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

★★★★★

Ответ на: комментарий от yvv

git shallow clone

Спасибо. А можно ли обойтись без клонирования всех файлов, скажем, слить только отдельную директорию или отдельный файл?

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

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

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

Можно сделать sparse checkout, но клонировать всё равно нужно всё репу.

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

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

sparse checkout,

Да, что-то такое и искал. А можно ли один раз выкачать всю репу, настроить sparse-checkout и удалить все ненужные файлы? Или они всё равно останутся в .git?

question4 ★★★★★
() автор топика

git clone –depth=1 … ?

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

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

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

gtk3 ★★★
()

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

Вы явно что-то делаете неправильно.

pinus_nigra
()

Если что, git - это про заср..ть винт иной, которая никогда не потребуется, в первую очередь, и про работу - во вторую.

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

А есть где-нибудь инструкция о том, как это делать?

Если мне не изменяет склероз то так:

svn co https://github.com/gde2-desktop/gde2-panel/trunk/gde2-panel/libegg
gtk3 ★★★
()
Ответ на: комментарий от yvv

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

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

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

Только толку от этого?

Например, если нужно компилировать только часть проекта.

yvv ★★☆
()
Ответ на: комментарий от 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)
Ответ на: комментарий от I-Love-Microsoft

В одной конторе наблюдал как много отдельных репов были, но сливались в один каталог.

Собственно, у нас именно так всё. Управляет репами самодельная утилитка.

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

Управляет репами самодельная утилитка.

У Google тоже: Repo.

gag ★★★★★
()

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

den73 ★★★★★
()

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

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

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

KillTheCat ★★★★★
()

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

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

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

Разбей свой проект на несколько реп, не мучайся

Во, советчики подъехали. А, может, под каждый файл отдельную репу завести?

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 ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.