Як зробити підмодулі з неглибокої кишки?

Чи можливо мати дрібні підмодулі? У мене є суперпроект з декількома підмодулями, кожен з яких має тривалу історію, тому він стає непотрібним великим перетягуванням всієї цієї історії.

Все, що я знайшов, - це нитка без відповіді .

Чи варто просто зламати git-підмодуль для цього?

Нове у майбутньому git1.8.4 (липень 2013) :

" git submodule update" може за бажанням клонувати дрібно сховища підмодулів.

(І git 2.10 Q3 2016 дозволяє записати це з git config -f .gitmodules submodule.<name>.shallow true.
Див. Кінець цієї відповіді)

Див. Комісію 275cd184d52b5b81cb89e4ec33e540fb2ae61c1f :

Додайте --depthпараметр до команд додавання та оновлення "підмодуля git", який потім передається команді clone. Це корисно, коли підмодулів (ів) величезна кількість, і ви насправді не цікавитесь нічим, окрім останньої версії.

Додано тести і були зроблені деякі корективи з відступом, щоб відповідати решті тестового файлу в розділі "Оновлення підмодуля може обробляти символічні посилання в pwd".

Підписаний: Фредрік Густафссон <iveqy@iveqy.com>
Акціонер: Єнс Леманн<Jens.Lehmann@web.de>

Це означає, що це працює:

git submodule add --depth 1 -- repository path
git submodule update --depth -- [<path>...]

З:

--depth::

Ця опція дійсна для addі updateкоманди.
Створіть "неглибокий" клон з історією, врізаною у вказану кількість змін.

atwyman додає в коментарях :

Наскільки я можу сказати, цей варіант не підходить для підмодулів, які не відслідковують masterдуже ретельно. Якщо ви встановите глибину 1, ви submodule updateзможете досягти успіху лише в тому випадку, якщо підмодуль, який ви хочете, є останнім майстром. Інакше ви отримаєте " fatal: reference is not a tree" .

Це правда.
Тобто до git 2.8 (березень 2016 року). З 2.8 у submodule update --depthшансів є ще один шанс на успіх, навіть якщо SHA1 знаходиться в безпосередній доступності від однієї з віддалених РЕПОГОЛОВІВ.

Див. Комісію fb43e31 (24 лютого 2016 р.) Від Стефана Беллера ( stefanbeller) .
Допомагає: Хуніо С Хамано ( gitster) .
^{(Об’єднав Хуніо С Хамано - gitster- у комітеті 9671a76 , 26 лютого 2016 р.)}

підмодуль: спробуйте сильніше отримати необхідний sha1 шляхом прямого отримання sha1

Переглядаючи зміну, яка також оновлює підмодуль у Герріті, поширеною практикою огляду є завантаження та вишневий вибір патча на локальному рівні, щоб перевірити його.
Однак під час тестування на локальному рівні " git submodule update" може не вдатися до отримання правильного підмодуля sha1, оскільки відповідна комісія в підмодулі ще не є частиною історії проекту, а є лише запропонованою зміною.

Якщо $sha1не було частиною вибору за замовчуванням, ми намагаємось отримати $sha1безпосередньо . Однак деякі сервери не підтримують функцію sha1, що призводить git-fetchдо швидкого виходу з ладу.
Тут ми можемо зазнати невдачі, оскільки все ще відсутній ша1 призведе до відмови пізніше на етапі оформлення каси, тому невдача тут настільки ж хороша, як ми можемо отримати.

MVG вказує в коментарях до скоєння fb43e31 (мерзотник 2,9, лютий 2016)

Здавалося б , що мені зробити fb43e31 запити відсутню здійснювати по SHA1 ідентифікатор, так uploadpack.allowReachableSHA1InWantі uploadpack.allowTipSHA1InWantнастройки на сервері, ймовірно , вплине це працює.
Я сьогодні написав допис до списку git , вказуючи, як використання мілководних підмодулів можна зробити так, щоб вони працювали краще для деяких сценаріїв, а саме, якщо фіксація також є тегом.
Почекаємо і подивимось.

Я думаю, це причина, чому fb43e31 зробив випуск для конкретного SHA1 після резервного відгалуження для гілки за замовчуванням.
Тим не менш, у випадку "-depth 1" я вважаю, що було б доцільно перервати рано: якщо жоден із перерахованих списків не відповідає запитуваному, а запит від SHA1 не підтримується сервером, то немає сенсу в отримуючи що-небудь, оскільки ми не зможемо задовольнити вимогу підмодулю.

Оновлення серпня 2016 року (через 3 роки)

З Git 2.10 (Q3 2016) ви зможете це зробити

 git config -f .gitmodules submodule.<name>.shallow true

Докладніше див. У підмодулі Git без зайвої ваги .

Git 2.13 (ІІ квартал 2017 р.) Додати в команді 8d3047c (19 квітня 2017 р.) Себастьяна Шуберта ( sschuberth) .
^{(Об’єднав Себастьян Шуберт - sschuberth- у комітеті 8d3047c , 20 квітня 2017 р.)}

клон цього підмодуля буде виконаний як дрібний клон (з глибиною історії 1)

Однак Циро Сантілі додає у коментарях (та деталі у своїй відповіді )

shallow = trueна .gitmodulesвпливає лише на посилання, яке відстежується HEAD дистанційного при використанні --recurse-submodules, навіть якщо цільовий комікс вказує на гілку, і навіть якщо ви також ставите branch = mybranchна .gitmodules.

Git 2.20 (Q4 2018) покращується на підтримці підмодуля, який було оновлено для читання з блоку, HEAD:.gitmodulesколи .gitmodulesфайл відсутній у робочому дереві.

Див. Фіксувати 2b1257e , фіксувати 76e9bdc (25 жовтня 2018 р.) Та здійснювати b5c259f , здійснювати 23dd8f5 , здійснювати b2faad4 , здійснювати 2502ffc , здійснювати 996df4d , здійснювати d1b13df , здійснювати 45f5ef3 , фіксувати bcbc780 (05 жовтня 2018 р.) Антоніо Оспіте ( ao2) .
^{(Об’єднав Хуніо С Хамано - gitster- у комісі abb4824 , 13 листопада 2018 р.)}

submodule: підтримка читання, .gitmodulesколи його немає в робочому дереві

Коли .gitmodulesфайл недоступний у робочому дереві, спробуйте використовувати вміст з індексу та з поточної гілки.
Це стосується випадків, коли файл є частиною сховища, але він чомусь не перевіряється, наприклад, через рідку перевірку.

Це дає можливість використовувати принаймні « git submodule» команди , які читають в gitmodulesконфігураційний файл без повного заповнення робочого дерева.

Для запису .gitmodulesвсе одно потрібно буде перевірити файл, тому перевірте це перед тим, як дзвонити config_set_in_gitmodules_file_gently.

Додайте також аналогічний чек, git-submodule.sh::cmd_add()щоб передбачити можливий збій команди " git submodule add", коли .gitmodulesце не є безпечним для запису; це заважає команді залишити сховище у хибному стані (наприклад, сховище підмодуля було клоновано, але .gitmodulesне оновлено через config_set_in_gitmodules_file_gentlyпомилку).

Більше того, оскільки config_from_gitmodules()тепер доступ до глобального сховища об'єктів, необхідно захистити всі кодові шляхи, які викликають функцію, від одночасного доступу до глобального об'єкта-магазину.
В даний час це відбувається тільки в builtin/grep.c::grep_submodules(), тому дзвоніть grep_read_lock()перед тим, як викликати включений код config_from_gitmodules().

ПРИМІТКА. Є один рідкісний випадок, коли ця нова функція ще не працює належним чином: вкладені підмодулі без .gitmodulesїхнього робочого дерева.

Примітка: Git 2.24 (Q4 2019) фіксує можливий сегмент за умов дрібного клонування підмодуля.

Див. Комісію ddb3c85 (30 вересня 2019 року) від Алі Утку Селен ( auselen) .
^{(Об'єднав Хуніо С Хамано - gitster- у комітеті 678a9ca , 09 жовтня 2019 р.)}

Git 2,25 (Q1 2020), уточнює git submodule updateдокументацію.

Див. Комісію f0e58b3 (24 листопада 2019 р.) Від Філіпа Блена ( phil-blain) .
^{(Об’єднав Хуніо С Хамано - gitster- в комісії ef61045 , 05 грудня 2019 р.)}

doc: згадайте, що 'git submodule update' отримує відсутні коміти

^{Допомагав: Хуніо С Хамано
Допомагав: Йоганнес Шинделін
Підписався: Філіп Блейн}

' git submoduleupdate' отримає нові коміти з віддаленого підмодуля, якщо SHA-1, записаний у надпроекті, не знайдений . Про це в документації не говорилося.

Попередження: В Git 2.25 (Q1 2020) взаємодія між " git clone --recurse-submodules" і альтернативним магазином об'єктів була погано розроблена.

Документацію та код навчають робити більш чіткі рекомендації, коли користувачі бачать збої.

Див. Команду 4f3e57e , виконайте 10c64a0 (02 грудня 2019 року) Джонатана Тана ( jhowtan) .
^{(Об’єднав Хуніо С Хамано - gitster- в комітеті 5dd1d59 , 10 грудня 2019 р.)}

submodule--helper: поради щодо фатальної альтернативної помилки

^{Підписаний: Джонатан Тан
Акцепт: Джефф Кінг}

Під час рекурсивного клонування суперпроекту з деякими дрібними модулями, визначеними в ньому .gitmodules, а потім повторне повторне повторне позначення " --reference=<path>", виникає помилка. Наприклад:

git clone --recurse-submodules --branch=master -j8 \
  https://android.googlesource.com/platform/superproject \
  master
git clone --recurse-submodules --branch=master -j8 \
  https://android.googlesource.com/platform/superproject \
  --reference master master2

не вдається:

fatal: submodule '<snip>' cannot add alternate: reference repository
'<snip>' is shallow

Коли альтернативну обчислювану з альтернативи суперпроекту неможливо додати, будь то в цьому чи іншому випадку, порадьте про налаштування параметра " submodule.alternateErrorStrategy" налаштування та використання " --reference-if-able" замість " --reference" при клонуванні.

Це докладно в:

З Git 2.25 (Q1 2020) взаємодія між "git-клоном - повторними підмодулями" та альтернативним сховищем об'єктів була погано спроектована.

Doc: поясніть підмодуль.alternateErrorStrategy

^{Підписаний: Джонатан Тан
Акцепт: Джефф Кінг}

Фіксувати 31224cbdc7 ( « clone: рекурсивні та посилання опції спрацьовує подмодуль чергується», 2016-08-17, Git v2.11.0-RC0 - злиття перерахованих в партії # 1 ) вчив Git підтримувати параметри конфігурації " submodule.alternateLocation" та " submodule.alternateErrorStrategy" на суперпроект .

Якщо " submodule.alternateLocation" налаштовано на " superproject" для надпроекту, щоразу, коли підмодуль цього суперпроекту клонований, він замість цього обчислює аналогічний альтернативний шлях для цього підмодулю з $GIT_DIR/objects/info/alternatesнадпроекту та посилається на нього.

Параметр " submodule.alternateErrorStrategy" визначає, що станеться, якщо на цей замінник не може бути посилання.
Однак незрозуміло, що клон протікає так, ніби не було вказано альтернативного варіанту, коли цей параметр не встановлений для " вмирання " (як це можна побачити в тестах у 31224cbdc7 ).
Тому документуйте це відповідно.

Документація конфігурації підмодуля тепер включає:

submodule.alternateErrorStrategy::

Вказує, як обчислювати помилки з альтернативними для підмодуля як обчислені через submodule.alternateLocation.
Можливі значення ignore, info, die.
За замовчуванням є die.
Зауважте, що якщо встановлено ignoreабо info, і якщо є помилка з обчисленим альтернативом, клон триває так, як ніби альтернативний варіант не вказаний .

Git 2.9.0 підтримує підмодулі дрібного клонування безпосередньо, тому тепер ви можете просто зателефонувати:

git clone url://to/source/repository --recursive --shallow-submodules

Після відповіді Райана я зміг придумати цей простий сценарій, який повторюється через усі підмодулі та їх дрібно клонує:

#!/bin/bash
git submodule init
for i in $(git submodule | sed -e 's/.* //'); do
    spath=$(git config -f .gitmodules --get submodule.$i.path)
    surl=$(git config -f .gitmodules --get submodule.$i.url)
    git clone --depth 1 $surl $spath
done
git submodule update

Читаючи через "джерело" git-підмодуля, схоже, git submodule addможе обробляти підмодулі, які вже мають свої сховища. В такому разі...

$ git clone $remote1 $repo
$ cd $repo
$ git clone --depth 5 $remotesub1 $sub1
$ git submodule add $remotesub1 $sub1
#repeat as necessary...

Ви хочете переконатися, що потрібна фіксація знаходиться в ремоді підмодуля, тому переконайтеся, що ви встановили відповідне --depth.

Редагувати: Можливо, ви зможете піти з кількох клонів вручну з підмодулями з подальшим одним оновленням:

$ git clone $remote1 $repo
$ cd $repo
$ git clone --depth 5 $remotesub1 $sub1
#repeat as necessary...
$ git submodule update

Коротка інформація про баггі / несподівану / дратівливу поведінку станом на Git 2.14.1

1. shallow = trueв .gitmodulesзачіпає тільки git clone --recurse-submodulesякщо HEADз віддалених точок підмодуля в потрібне зобов'язання, навіть якщо мета коммітов вказує гілка, і навіть якщо ви поставите branch = mybranchна.gitmodules а.

   Локальний тестовий сценарій . Така ж поведінка в GitHub 2017-11, де HEADконтролюється налаштування репо за замовчуванням:

   git clone --recurse-submodules https://github.com/cirosantilli/test-shallow-submodule-top-branch-shallow
   cd test-shallow-submodule-top-branch-shallow/mod
   git log
   # Multiple commits, not shallow.
   

2. git clone --recurse-submodules --shallow-submodulesне виконується , якщо зобов'язання не є ні посилається відгалуження або мітки з повідомленням: error: Server does not allow request for unadvertised object.

   Локальний тестовий сценарій . Така ж поведінка на GitHub:

   git clone --recurse-submodules --shallow-submodules https://github.com/cirosantilli/test-shallow-submodule-top-sha
   # error
   

   Я також запитав у списку розсилки: https://marc.info/?l=git&m=151863590026582&w=2, і відповідь:

   Теоретично це повинно бути легко. :)

   На практиці не так вже й багато, на жаль. Це тому, що клонування просто отримає останню підказку гілки (як правило, головного). Не існує механізму в клоні, який би вказував потрібний sha1.

   Протокольний протокол підтримує запитання точних ша1, так що їх слід охопити. (Caveat: він працює лише у тому випадку, якщо оператор сервера дозволяє uploadpack.allowReachableSHA1InWant, який github не має AFAICT)

   git-fetch дозволяє отримати довільну sha1, тому в якості обхідного варіанту ви можете запустити виборку після рекурсивного клону, використовуючи "оновлення підмодуля git", оскільки це використовуватиме вибори після початкового клонування.

Тест TODO: allowReachableSHA1InWant.

Чи віддалені канонічні місця для ваших підмодулів? Якщо так, то чи гаразд ви їх клонували один раз? Іншими словами, чи хочете ви мілководні клони лише тому, що ви страждаєте витраченою пропускною здатністю частих підмодульних (пере) клонів?

Якщо ви хочете, щоб мілкі клони зберегли місцевий диск, тоді відповідь Райана Грема виглядає як хороший шлях. Клоніруйте сховища вручну, щоб вони були неглибокими. Якщо ви думаєте, що це було б корисно, адаптуйтеся, git submoduleщоб підтримати його. Надішліть до списку електронний лист із запитом про нього (поради щодо його реалізації, пропозиції щодо інтерфейсу тощо). На мою думку, люди, які підтримують потенційну роботу, підтримують потенційних учасників, які щиро хочуть посилити Git конструктивними способами.

Якщо ви все в порядку, роблячи один повний клон кожного підмодуля (плюс пізніші вибори для того, щоб вони були в курсі), ви можете спробувати скористатися --referenceпараметром git submodule update(він знаходиться в Git 1.6.4 і пізніших версіях) для звернення до локальних магазинів об'єктів (наприклад, роблять --mirrorклони канонічних сховищ підмодулів, потім використовуйте --referenceу своїх підмодулях, щоб вказати на ці локальні клони). Просто не забудьте прочитати про git clone --reference/ git clone --sharedперед використанням --reference. Єдиною ймовірною проблемою із посиланням на дзеркала буде, якщо вони коли-небудь отримають нешвидкісні оновлення вперед (хоча ви можете ввімкнути відкладені файли та розширити свої вікна закінчення терміну дії, щоб допомогти зберегти будь-які покинуті комісії, що можуть спричинити проблему). У вас не повинно виникнути жодних проблем

• ви не приймаєте жодних локальних підмодулів, або
• будь-які коміти, залишені звисаючими не швидкими пересиланнями, які канонічні сховища можуть публікувати, не є пращурами місцевих комітетів підмодулю, або
• ви старанно ставитесь до того, щоб ваш локальний підмодульний комітет переосмислився поверх того, що може бути опубліковано у сховищах канонічних підмодулів.

Якщо ви працюєте з чимось подібним, і є ймовірність, що ви можете перенести локальні підмодулі у ваші робочі дерева, можливо, було б хорошою ідеєю створити автоматизовану систему, яка гарантує, що критичні об'єкти, на які посилаються перевірені підмодулі, не є залишено звисати в дзеркальних сховищах (і якщо такі знайдеться, скопіюйте їх у сховища, які їм потрібні).

І, як git cloneкаже вхідна сторінка, не використовуйте, --referenceякщо ви не розумієте цих наслідків.

# Full clone (mirror), done once.
git clone --mirror $sub1_url $path_to_mirrors/$sub1_name.git
git clone --mirror $sub2_url $path_to_mirrors/$sub2_name.git

# Reference the full clones any time you initialize a submodule
git clone $super_url super
cd super
git submodule update --init --reference $path_to_mirrors/$sub1_name.git $sub1_path_in_super
git submodule update --init --reference $path_to_mirrors/$sub2_name.git $sub2_path_in_super

# To avoid extra packs in each of the superprojects' submodules,
#   update the mirror clones before any pull/merge in super-projects.
for p in $path_to_mirrors/*.git; do GIT_DIR="$p" git fetch; done

cd super
git pull             # merges in new versions of submodules
git submodule update # update sub refs, checkout new versions,
                     #   but no download since they reference the updated mirrors

Або замість цього . Вам потрібно буде повторно використати будь-які існуючі перевірені підмодулі, щоб отримати жорсткі посилання. Ви б економили пропускну здатність, завантажуючи лише один раз у дзеркала, а потім витягуючи їх локально з тих, хто перейшов у перевірені підмодулі. Жорстке посилання дозволить заощадити дисковий простір (хоча збірки, як правило, накопичуються та дублюються в декількох екземплярах об'єктних сховищ перевірених підмодулів; ви можете періодично повторно відновлювати перевірені підмодулі з дзеркал, щоб повернути заощаджений дисковий простір, який надає жорстке посилання).--reference ви можете використовувати дзеркальні клони в поєднанні з функцією жорсткого посилання за замовчуванням git clone, використовуючи локальні дзеркала як джерело для своїх підмодулів. У нових клонах суперпроектів виконайте git submodule initредагування URL-адрес підмодуля, .git/configщоб вказати на локальні дзеркала, а потім зробітьgit submodule update

Я створив дещо іншу версію, бо коли вона не працює на межі кровотечі, що не всі проекти роблять. Стандартні допоміжні доповнення не спрацювали, як і сценарій вище. Тому я додав хеш-пошук для ref тегу, і якщо його немає, він повертається до повного клону.

#!/bin/bash
git submodule init
git submodule | while read hash name junk; do
    spath=$(git config -f .gitmodules --get submodule.$name.path)
    surl=$(git config -f .gitmodules --get submodule.$name.url)
    sbr=$(git ls-remote --tags $surl | sed -r "/${hash:1}/ s|^.*tags/([^^]+).*\$|\1|p;d")
    if [ -z $sbr ]; then
        git clone $surl $spath
    else
        git clone -b $sbr --depth 1 --single-branch $surl $spath
    fi
done
git submodule update 

Посилання на як клонувати репозиторій git із певним набором змін / змін?

Я написав простий сценарій, який не має жодних проблем, коли ваша посилання на підмодуль знаходиться далеко від головного

git submodule foreach --recursive 'git rev-parse HEAD | xargs -I {} git fetch origin {} && git reset --hard FETCH_HEAD'

Це твердження отримає посилання на версію підмодуля.

Це швидко, але ви не можете здійснити редагування на підмодулі (попередньо його потрібно зняти) https://stackoverflow.com/a/17937889/3156509 )

повністю:

#!/bin/bash
git submodule init
git submodule foreach --recursive 'git rev-parse HEAD | xargs -I {} git fetch origin {} && git reset --hard FETCH_HEAD'
git submodule update --recursive

Неглибокий клон підмодуля ідеально підходить, оскільки вони знімають при певному наборі редагування / зміни. Завантажити поштовий індекс з веб-сайту легко, тому я спробував створити сценарій.

#!/bin/bash
git submodule deinit --all -f
for value in $(git submodule | perl -pe 's/.*(\w{40})\s([^\s]+).*/\1:\2/'); do
  mysha=${value%:*}
  mysub=${value#*:}
  myurl=$(grep -A2 -Pi "path = $mysub" .gitmodules | grep -Pio '(?<=url =).*/[^.]+')
  mydir=$(dirname $mysub)
  wget $myurl/archive/$mysha.zip
  unzip $mysha.zip -d $mydir
  test -d $mysub && rm -rf $mysub
  mv $mydir/*-$mysha $mysub
  rm $mysha.zip
done
git submodule init

git submodule deinit --all -f очищає дерево підмодуля, що дозволяє повторно використовувати сценарій.

git submoduleотримує 40 char sha1, за яким слідує шлях, відповідний тому самому в .gitmodules. Я використовую perl для об'єднання цієї інформації, розділеної двокрапкою, а потім використовую змінну трансформацію для розділення значень на myshaтаmysub .

Це найважливіші ключі, оскільки нам потрібно sha1 для завантаження та шлях до співвідношення url в .gitmodules.

Дано типовий запис підмодуля:

[submodule "label"]
    path = localpath
    url = https://github.com/repository.git

myurlpath =потім клавіші клацнуть через 2 рядки, щоб отримати значення. Цей метод може не працювати послідовно і вимагати доопрацювання. Заголовок URL-адреси знімає будь-які .gitпосилання, що залишилися, шляхом відповідності останньому /та будь-яким із них ..

mydirє mysubмінусом остаточного/name який би по каталогу, що веде до імені підмодуля

Далі - a wget формат завантаженого URL-адреси архіву zip. Це може змінитися в майбутньому.

Розпакуйте файл, до mydirякого буде підкаталог, вказаний у шляху субмодуля. Отримана папка буде останнім елементом url- sha1.

Перевірте, чи існує підкаталог, вказаний у шляху субмодуля, і видаліть його, щоб дозволити перейменування вилученої папки.

mv перейменуйте вилучену папку, що містить наш sha1, у її правильний шлях до підмодуля.

Видалити завантажений zip-файл.

Підмодуль init

Це скоріше доказ WIP концепції, а не рішення. Коли він працює, результат - це дрібний клон підмодуля у визначеному наборі змін.

Якщо репозиторій повернеться в домашній підмодуль до іншого фіксації, повторно запустіть скрипт для оновлення.

Єдиний сценарій, подібний до цього, буде корисним для локальної побудови вихідного проекту.