blob: 0f3d2232535a8774e1a03bbdcd110b316636e4f6 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2015-02-27T19:45:27Z"
content="""
One way that seems to work to use submodules with git-annex:
* Replace the submodule's .git file with a symlink to the location the
contents of the file pointed at. (Eg, ../.git/modules/$whatever)
* Unset core.worktree in the submodule's .git/config, which will
normally be set by git when checking out a submodule.
With this configuration, git seems to work ok (although it's hard to tell
if there might be some code path that requires .git to be a file and not a
directory.. seems unlikely though!). And, git-annex works fine, because
it uses paths relative to the .git symlink, so
".git/annex/objects/xx/yy/sha/sha" is in the symlink target like usual.
Converting .git to a symlink also means that the same repo that is used
as a submodule can be moved to a different "mount point" in the parent
repo, or used standalone, and the git-annex object links in it will
continue to work.
Looking at the git code, it would be a problem if a code path called
read_gitfile without also checking is_git_directory or similar. Auditing
the code, I have found a lot of places that are careful to check both
possibilities, and none that are a problem with a .git directory;
although I don't understand all the git code so not 100% sure.
Since a submodule will have core.worktree set, git-annex
could cheaply check that with nearly no overhead as a first pass to
detect a submodule, and then do whatever might be appropriate to support
submodules -- such as replacing .git with a symlink.
"""]]
|
