Is deleting old branches in Git submodules safe w.r.t. usable history of 'supermodules'?

If I use a workflow like this:

• app_repo and app2_repo have a common submodule, library_repo.
• In library_repo, I make a library_feature branch to work on a new feature while leaving master stable.
• app2_repo needs the new feature, so I track the submodule development in it (i.e. I update the submodule reference as commits are made to library_repo). In tandem to this, changes are being made to the app2_repo source too (the app is under development also).
• After the feature is finished, I merge the library_feature branch in library_repo back into library_repo's 开发者_JS百科master branch.
• Deveopment continues, with app2_repo now inluding library_repo's master again.
• I delete library_repo's library_feature branch, now that the history is merged into master, to keep things 'clean'.

Have I just lost the ability to check out historic app2_repo SHAs and have 'submodule update' update correctly with the relevant historical commits from library_repo, because I deleted the library_feature branch that they were in, or will all the relevent commits still be there, because the history is now shared with master now it's merged?

All the relevant commits will still be there.

When you create a commit with a submodule at a particular version, the only information stored in the tree of the "supermodule" is the object name (i.e. SHA1sum) of the commit that the submodule should be at. So, deleting the branch once it's been merged into master will make no difference - all your old commits in the supermodule will point to the object names of commits that are still in the history of master in the submodule.

If you had deleted a branch which isn't merged into some other branch, the unmerged commits on that branch would eventually be garbage collected and that might create the problem you're worried about, but you've explicitly said here that everything was merged before deleting the branch.