Блог

Моя структура репозитория:

 repo_a
└── repo_b
    └── .gitconfig
  

repo_b является подмодулем.
.gitconfig :

 [alias]
    b = branch
  

Как я могу добавить такой путь .gitconfig , который repo_b может использовать только его?

Ожидаемый результат:

 $ cd repo_a
$ git b
git: 'b' is not a git command. See 'git --help'.
$ cd repo_b
$ git b
* master
  

Правка #1:

Ответы от @jthill и @bk2204 хороши.
Они описывают, как получить доступ к файлу конфигурации для подмодуля с помощью:

 git rev-parse --git-path config
  

Я хочу указать, что я хочу.
Я хочу, чтобы изменения в .gitconfig файле repo_b отслеживались git. Так что при клонировании только repo_b у меня также будет доступ к тому же .gitconfig самому.
Решение от @jthill кажется возможным. Тем не менее, это также кажется довольно подверженным ошибкам, и мне пришлось бы добавлять хук для каждого отдельного изменения в git, которое может изменить .gitconfig . Например git pull , git checkout , git merge .

Таким образом, мой вопрос будет состоять из 2 частей:

1. Как я могу отслеживать изменения repo/.gitconfig и использовать его как локальный конфигурационный файл?
2. Как я могу реализовать указанную функциональность как для обычного репозитория, так и для подмодуля?

Если вы ищете эквивалент .git/config для подмодуля, то самый простой способ найти его — запустить git rev-parse --git-path config изнутри repo_b . Это самый простой способ настроить конфигурацию для локального репозитория.

Вы не можете поместить .gitconfig файл в репозиторий и ожидать, что он будет использоваться; совместное использование конфигурации в репозитории небезопасно, поэтому Git этого не разрешает.

Если вы хотите отредактировать локальную конфигурацию с git config помощью , вы можете сделать это, перейдя в repo_b .

Я не думаю, что это возможно:

Читая раздел руководства по Git, соответствующий конфигурации подмодулей, кажется, что 2 возможных варианта:

• Создание файла, вызываемого config в корне подмодуля
• Добавление содержимого в .gitmodules файл суперпроекта

Я попытался добавить псевдоним в оба этих файла, но псевдоним не вступил в силу.

Редактировать:

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

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

В качестве smoketest вы можете попросить людей, использующих репозиторий, выполнить

 cat .gitconfig >>$(git rev-parse --git-dir)/config
  

и это добавит ваши конфигурации в настройки репозитория. Для более безопасной версии,

 sed -si '/^# --repo-b-config--$/,/^# --repo-b-config--$/d; $r .gitconfig' 
        $(git rev-parse --git-dir)/config
  

и имейте # --repo-b-config-- строки вверху и внизу вашего специального файла.

Git намеренно не позволяет fetch переопределять административные параметры. Невозможно заставить fetch что-либо узурпировать. Ваш репозиторий принадлежит вам. Вы решаете, что в нем происходит, и это означает, что никто другой ничего не сможет проникнуть, если вы сами не создадите для них путь. Вы можете запускать произвольные команды при оформлении заказа для обновления локальной конфигурации или чего-либо еще, но в вашем репозитории, в каждом репозитории, который вы администрируете (включая, например, каждое репозиторий, который вы создаете с git clone помощью или git init или git submodule update --init ), вы контролируете, что это за команды.

Итак, если вы хотите, чтобы вышеуказанное sed выполнялось после каждой проверки, поместите (возможно, исправленную версию) в это репозиторий hooks/post-checkout , и у вас будет то, что вы хотите.

Я не реализовал эту функцию из соображений безопасности.

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