I work a lot with

The background:

I have a repository that contains several other embedded repositories. I manage all the embedded repos using a manifest file (a text file listing each repository and its associated commit and brach) and when I want to sync them I simply checkout the relevant branches and commits based on the manifest file using a bash script I wrote. I am building an app that implements a multi-repo management solution that combines features from submodules and google's repo with the addition of a graphical user interface. That is why I am purposely not using submodules here.

CodePudding user response：

I manage all the embedded repos using a manifest file (a text file listing each repository and its associated commit nd brach) and when I want to sync them I simply checkout the relevant branches and commits based on the manifest file using bash script I have.

You do understand that your bash script implements submodules, right? .gitmodules is a text file listing tracked histories, the origin repositories used to fetch them and the various options you like to use when working with them, and git adding a nested repository lists it in the Git manifest aka index.

If you're wedded to the way you're doing things, I'd suggest a pre-commit hook that scrapes any added gitlinks out of the index and updates-and-re-adds your manifest file, then maybe pops a note if it made any changes. This would be like a five-liner (just like a large majority of git submodule commands can be implemented as five-liners).

git ls-files -cs | grep ^16

will list all your tracked histories. Assuming to keep things simple that you keep your manifest file keyed in that format the update is a straight sort -t$'\t' -usk2,2 | join pipe.