From 2cb79146995325a73dfd3ec540c6d9262c341c7f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 19 Jan 2022 11:56:00 -0400 Subject: [PATCH] commeent --- ..._63f30b652c0cbdb0acf6745891f9f09e._comment | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 doc/tips/using_nested_git_repositories/comment_2_63f30b652c0cbdb0acf6745891f9f09e._comment diff --git a/doc/tips/using_nested_git_repositories/comment_2_63f30b652c0cbdb0acf6745891f9f09e._comment b/doc/tips/using_nested_git_repositories/comment_2_63f30b652c0cbdb0acf6745891f9f09e._comment new file mode 100644 index 0000000000..bc6b5fbdd7 --- /dev/null +++ b/doc/tips/using_nested_git_repositories/comment_2_63f30b652c0cbdb0acf6745891f9f09e._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2022-01-19T15:51:17Z" + content=""" +I agree, submodules are the usual way to nest git repositories, and will +more or less just work with git-annex. + +I think that the author of this tip is wanting to version control the +contents of `.git` itself. Eg, to version control `.git/config` and +`.git/hooks/`. + +One problem with this approach is that when the outer repository has +"dotgit/annex/objects/` files added to it, running `git-annex drop` inside +the nested git repository will drop the content, but the outer repository +will still contain a copy too. You would have to use `git-annex unused` +to eventually clean up those copies. And it stores 2 copies of every +annexed file to use it this way. +"""]] -- 2.39.5