Как написать портативные скрипты библиотеки Git?

Question

Я создаю пользовательские команды Git, написав сценарии в /usr/local/libexec/git и создавая псевдонимы для их вызова. Например:

git config --global alias.graph '!/usr/local/libexec/git/git-graph' 

Хитрость в том, что я хочу, чтобы мои скрипты, чтобы быть «портативный» в том смысле, что любой, кто установил Git должен быть в состоянии установить и запустить мои сценарии так же, как и я, не встречая отсутствующие зависимости.

Важное замечание: После ответа Шверна я понимаю, что должен добавить немного дополнительную информацию. Замените «любого, кто установил Git», с «любым, кто взаимодействует с Git через скрипты git-core, предоставленные официальными источниками Git». Например, вызов git rebase выполняет .../git-core/git-rebase.sh. (Вы можете щелкнуть это последнее слово, это гиперссылка, но во всех браузерах это не так). Я предполагаю, что это ситуация для большинства пользователей Git, поскольку это по умолчанию предоставляется самим проектом Git.

Из моего многолетнего опыта работы portable shell scripts, я знаю, что бесполезно ожидать, что сценарий оболочки даже с умеренной степенью сложности будет работать на всех Unix-подобных ОС, которые когда-либо существовали. Тем не менее, я думаю, что разумно ожидать, что между рабочими станциями Git будет существовать общая база коммунальных услуг, по крайней мере, достаточно, чтобы постоянно перескакивать через обручи и ходить по яичной скорлупе при написании сценариев для работы на этих рабочих станциях.

Вот мои предположения о рабочих станциях Git:

• Все скрипты в каталоге git-core (например, /usr/libexec/git-core) не были изменены с момента его помещают туда установки Git.
• Все сценарии в git-core работают так, как ожидалось (например, на рабочих станциях Git, или кто-либо с «нормальной» настройкой).
• Установленная версия Git удовлетворяет некоторым минимальным требованиям, которые я решил поддержать своими сценариями. Редактировать: «Произвольно», я действительно имел в виду «удобный». @Schwern заявил с точностью, что я действительно пытался сказать здесь.

Как определить общую базу утилит, которые я могу использовать для написания переносных скриптов на этих рабочих станциях Git?

Edit: Я в основном ищу список зависимостей для git-core сценариев, представленных в основном дистрибутиве Git. Это даст общую базу, которую я ищу.

Answer 1

Больше нет такой вещи, как «рабочая станция Git», чем есть «рабочая станция SVN» или даже «рабочая станция Ruby». Это всего лишь машина, на которой установлен Git, и используется для работы или получения проекта, который использует Git. Если они находятся в среде Windows, это будет Windows. Если они находятся на устаревшей машине Solaris, это будет среда Solaris. Поскольку Git теперь входит в стандартную комплектацию OS X, каждая машина OS X является «рабочей станцией Git».

Поскольку «Рабочая станция Git» включает в себя Windows, а Windows не поставляется с любыми обычными утилитами оболочки, вы не можете использовать оболочку вообще. В лучшем случае вы можете положиться на минимальный набор, который поставляется с Git Bash, но есть множество установок Windows/Git, которые не используют Git Bash. Вместо этого многие IDE поставляются вместе с Git.

Ничто из этого не меняет проблемы совместимости при написании переносимых сценариев оболочки. BSD против Gnu против какого-то коммерческого монстра, и все с проблемой о том, что с Windows, все это будет.

Ничего из этого не изменилось, если говорить об установке сторонних расширений. Они не входят в /usr, это для системного материала и должно оставаться неизменным. Они идут примерно как /usr/local или даже ~/bin. Сценарии Git будут работать, если они находятся в PATH пользователя.

---

Как некоторые из ваших предположений о Git ...

Все скрипты в ГИТ-ядро каталога (например,/USR/libexec/ГИТ-ядро) не были изменены с момента его размещенных там установкой Git.

Это справедливое предположение ... если оно существует. Здесь на OS X нет /usr/libexec/git-core, и я не могу найти эквивалент. Я подозреваю, что все они скомпилированы в двоичный файл. Вы не можете предположить, что Git - это куча скриптов или даже имеет жесткие ссылки совместимости, такие как MacPorts.

Все скрипты в GIT-ядра выполняются как ожидалось (т.е. такие же, как на рабочих станциях мерзавец мейнтейнера, или кто-либо с „нормальной“ настройки).

Опять же, это прекрасное предположение , если они существуют, которые они не должны.

Установленная версия Git удовлетворяет некоторым минимальным требованиям, которые я решил поддержать своими сценариями.

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

---

Со всем, что в виду, чтобы быть портативным ...

• Использование git напрямую, а не через скрипты.
• Не Предположим, что «git» - это ничего, кроме двоичного кода git.
• Попросите установщика указать местоположение двоичного файла пользователя git.
• Не сбрасывайте свои собственные расширения в/usr/libexec, поместите их где-нибудь в PATH пользователя.
• Не жесткий код любого из путей, где будут установлены ваши расширения.
• Не напишите что-нибудь в оболочке или используя утилиты Unix.
• Используйте скомпилированный язык и предоставляйте двоичные файлы или обычно используемый язык сценариев, например Perl или Python или Ruby, и предоставляйте двоичные пакеты.

Answer 2

На самом деле, все Git встроенного в скриптах (есть много, в основном sh и несколько perl) живут в этом git-core каталоге. Запуск git xxx пытается выполнить программу git-xxx, как правило, из каталога git-core после настройки различных переменных окружения. Например, git --git-dir=/path/to/some/dir экспортирует настройку GIT_DIR=/path/to/some/dir.

Точное местоположение из git-core само по себе устанавливается при создании Git. Вы можете просмотреть его командой:

git --exec-path 

Обратите внимание, что в то время как git foo будет пытаться запустить $(git --exec-path)/git-foo, если нет в наличии нет git-foo и вы положили git-foo в вашем собственный каталог сценариев (то есть где-то на вашем $PATH), git foo закончится бег что. Механизм проста: git передний конец вставляет мерзавец-жильный путь в передней части $PATH:

$ cat << 'end' > $HOME/scripts/git-statusy 
? #! /bin/sh 
? echo statusy: \$PATH is $PATH 
? git status 
? 'end' 
$ chmod +x $HOME/scripts/git-statusy 
$ git statusy 
statusy: $PATH is /usr/local/libexec/git-core:[...snipped] 
On branch master 
... [snipped] 

В каталоге git-core, есть файл с именем git-sh-setup (г.о.). Это содержит некоторые удобные функции и некоторые обходные пути для известных проблем в системах, для которых построен Git. Поэтому «основной» сценарий Git должен начинаться с . git-sh-setup. (Это работает, потому что $PATH имеет каталог git-core на передней панели.) Некоторые «неосновные» сценарии Contrib явно запускают . $(git --exec-path)/git-sh-setup, хотя.

Внутри вашего скрипта вы можете зависеть от любых встроенных модулей оболочки POSIX, за исключением того, что вам нужно обойти некоторые ошибки (например, в некоторых версиях FreeBSD/bin/sh mishandles return). Насколько мне известно, поддержка дополнительных команд в основном основана на «как обнаружено путем тестирования»: если вы посмотрите на историю git-sh-setup.sh и других файлов .sh в источнике Git, вы увидите, что со временем произойдут различные изменения такие вещи.