Удаление git подмодулей - как автоматизировать удаление при нажатии?

Я прочитал как сам подмодуль git:

# Delete the relevant section from the .gitmodules file.
git config -f .gitmodules --remove-section submodule.$submodulepath
# Delete the relevant section from .git/config
git config -f .git/config --remove-section submodule.$submodulepath
git rm --cached path_to_submodule    # no trailing slash
git commit
rm -rf path_to_submodule

Я могу это сделать. Но когда кто-то еще делает git pull, как мы гарантируем, что подмодуль удаляется из их системы? Изменение .gitmodules происходит с тягой, но не намного больше, насколько я могу судить. Таким образом, человек, который потянул, все равно должен был бежать

git config -f .git/config --remove-section submodule.$submodulepath
rm -rf path_to_submodule

Это правильно? В небольшой команде разработчиков, я думаю, вы могли бы просто сказать всем, чтобы они выполняли эти команды, но это было не так идеально.

Есть ли какая-нибудь волшебная команда, которая автоматизирует это? В частности, мне бы хотелось, чтобы какой-то стандартный способ автоматизировать это в сценариях развертывания. С головы до ног я не уверен, как скрипты даже знают, что есть еще один субмодуль, чем раньше. (Не особенно привлекательны) варианты, которые возникают у меня:

  • выполняет различие в .gitmodules до и после нажатия
  • удалите все подмодули, а затем запустите git submodule update --init каждое развертывание.
  • Subodule в конечном итоге становится невоспроизводимым файлом после pull, поэтому будет работать, чтобы удалить все неподготовленные каталоги, которые содержат подкаталог .git после натяжения, но вы можете удалить нужные вещи чтобы сохранить этот путь.

Любые лучшие варианты оценены.

Ответы

Ответ 1

Для развертывания кода на серверах, имеющих git clean run after pull (например, с помощью тэга post-checkout), это безопасный вариант.

Что касается обновления репозиториев разработчиков, где запуск git clean является опасным, я не знаю другого способа, чем обрезка вручную.

Однако следующий (непроверенный) script сделает это автоматически, назовите его чем-то вроде git prune-submodules. Это связано с тем, что после git pull удаленные подмодули все еще перечислены в .git/config, поэтому вы можете узнать, какой из них нужно заархивировать.

Я новичок в сценариях оболочки, поэтому, пожалуйста, дважды проверьте.

#!/bin/sh
#get the list of submodules specified in .git/config
#http://stackoverflow.com/info/1260748/how-do-i-remove-a-git-submodule#comment9411108_7646931
submodules_cfg=`git config -f .git/config -l | cut -d'=' -f1 | grep "submodule.$MODPATH" | sed 's/^submodule\.//' | sed 's/\.url$//'`

#get the list of current submodules
submodules=`git submodule | cut -b 2- | cut -d' ' -f 2`

#archive submodule if listed in .git/config but doesn't exist anymore
for submodule_cfg in $submodules_cfg; do
    submodule_cfg_exists=0
    for submodule in $submodules; do
         if [ "$submodule" == "$submodule_cfg" ]; then
              submodule_cfg_exists=1
         fi
    done

    if ["$submodule_cfg_exists" == 0]; then
        mkdir -p archived-submodules
        mv $submodule_cfg archived-submodules/
        git config -f .git/config --remove-section submodule.$submodule_cfg
    fi
done