[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
 nickname="Abdó"
 subject="comment 6"
 date="2013-11-21T20:04:22Z"
 content="""
After I wrote my last post in this thread I did write a patch for git doing two things:

* make git ignore .git only at the root of the working tree, but not '.git' files or directories nested deeper into the working tree. 
* add config option to prevent git from converting directories containing .git into gitlinks. It turns out that git already has an internal setting for this, it only needed to be exposed in the config files!

It kind of worked, but I've never used nor completed this, though (if I recall correctly, something had to be done regarding the default gitingores, which contains .git). I don't think upstream would accept these changes, though. It is a potentially risky change that does not gives them any benefit. Plus commiting a git repo inside an other is kind of crazy. I'm not convinced this is a good solution anymore.

Being able to put a git repo inside an assistant-controled directory would be nice, though. Additionally, letting the outermost git repo recognize the internal git repo as a git repo, instead of moving files blindly, would also be nice, and probably more reasonable. And that leads to submodules...

My particular problem is: I want to syncing a directory with lots of little git repos across several machines, without having to configure remotes for every single one of them (so no mr) and having someone take care of the files which are ignored by the little git repos, possibly as annexed files. Currently I just sync that folder containing the little git repos with unison.

Now, instead of commiting git repos inside git repos, I'm more inclined to a potential solution using git-annex + submodules. Ideally I'd like something like this:

1. A git-annex repo at ~/work
2. All my little git repos inside ~/work are automatically recognized as submodules by git-annex
3. The outermost git-annex takes care of the .gitignored files for the inner git repos
4. git pull/push --recursive on the outermost annex repo pulls/pushes submodules (I think [something like this](https://github.com/jlehmann/git-submod-enhancements/wiki/Recursive-submodule-checkout) is written by  Jens Lehmann)
5. The urls in .gitmodules are relative paths from the outermost annex working tree. Then a git fetch --recursive from the outermost annex can use an outermost remote + the submodule relative path. No need to manually configure remotes for every machine on every submodule!

The problem with this approach, is that 2,4,5 are science-fiction for now, and probably 3 too. Realizing this would imply a lot of work, and commiting a lot of submodule stuff to upstream git. But probably stuff that makes sense and they would accept. Anyway, I'd like to know what Joey thinks about all this...
"""]]