Для обычной установки, которую вы описали здесь, с вложенностью рабочего дерева, соответствующей вложенности подмодуля, вы можете
mytoplevel=`git rev-parse --show-toplevel`
abovethat=`git -C "$mytoplevel"/.. rev-parse --show-toplevel`
Тогда
echo ${mytoplevel#$abovethat/}
даст вам путь к подмодулюв суперпроекте, или вы можете
echo ${PWD#$abovethat/}
, чтобы получить путь вашего текущего каталога относительно суперпроекта.
Итак:
me=`git rev-parse --show-toplevel`
up=`git -C "$me"/.. rev-parse --show-toplevel`
subpath=${me#$up/}
git -C "$up" config -f .gitmodules --get-regexp '^submodule\..*\.path$' ^$subpath$
возвращает вам подмодуль текущего репоимя и путь из записи config в его суперпроекте.
Git может быть полезен в любой мыслимой системе сборки;он не накладывает ограничений на то, как устроены вещи, находящиеся за пределами его компетенции.Так что, если не считать исчерпывающего поиска в пространстве имен файловой системы, вы не можете быть уверены, что нашли, что все используют любое рабочее дерево в качестве проверки субмодуля, у Git просто нет оснований заботиться о том, как используется репозиторий.
ДляНапример, если все проекты должны запускаться с одной и той же подмодульной версии, у вас может быть один репозиторий, а рабочее дерево служит общим подмодулем для них всех: вместо того, чтобы проходить через каждый из них и делать синхронизированные проверки, а затемполагая, что вы не пропустили ни одного, просто используйте одно репо с одним рабочим деревом и укажите всем, кто его использует.
Для рабочих процессов с такой необходимостью это может быть значительно лучше, чем при обычной настройке, все пользователипо определению см. синхронизированную текущую версию субмодуля, и любой клиент, которому необходимо знать «что нового» с обновлением, может, например, git -C utils diff `git rev-parse :utils` HEAD
, каждый пользователь субмодуля эффективно имеет свою собственную ветвь отслеживания и может использовать все инструменты Git, чтобы оставаться в курсе илиразрешать конфликты.
Итак, чтобывоссоздайте ваши настройки, я делаю:
git init git_repo; cd $_
mkdir a/b; git init a/b/c; cd $_
mkdir something; touch something/somefile;
git add .; git commit -m-
cd `git -C .. rev-parse --show-toplevel`
git submodule add --name foo/bar ./a/b/c -- a/b/c
git add .; git commit -m-
Затем я получаю это при попытке:
$ find -print -name .git -prune
.
./a
./a/b
./a/b/c
./a/b/c/something
./a/b/c/something/somefile
./a/b/c/.git
./.gitmodules
./.git
$ git grl
core.repositoryformatversion 0
core.filemode true
core.bare false
core.logallrefupdates true
submodule.foo/bar.url /home/jthill/src/snips/git_repo/a/b/c
submodule.foo/bar.active true
$ cd a/b/c/something
$ me=`git rev-parse --show-toplevel`
$ up=`git -C "$me"/.. rev-parse --show-toplevel`
$ subpath=${me#$up/}
$ git -C "$up" config -f .gitmodules --get-regexp '^submodule\..*\.path$' ^$subpath$
submodule.foo/bar.path a/b/c
$ echo $me $up $subpath
/home/jthill/src/snips/git_repo/a/b/c /home/jthill/src/snips/git_repo a/b/c
Если есть разница между этой настройкой и тем, что выЯ описал, я упускаю это, у меня есть структура каталогов, имя подмодуля, начальный каталог ... если вы пройдете через это и найдете, где настройки или результаты отличаются от ваших, я думаю, чтопомощь.