Hi, Antony Stubbs wrote: > I have a special situation (maven git scm provider) where I have sub > directories with git repps in them which I use as data to run tests > on. > > Is it possible to track these "internal" repos without using submodules? First I should say that whatever I say below is about git of the present, not git of the future. In other words, if you have a patch that would change this without breaking things, go for it. Okay, so why does git not allow adding files or directories named .git? The first hint is in dir.c: | /* | * Read a directory tree. We currently ignore anything but | * directories, regular files and symlinks. That's because git | * doesn't handle them at all yet. Maybe that will change some | * day. | * | * Also, we ignore the name ".git" (even if it is not a directory). | * That likely will not change. | */ | static int read_directory_recursive(struct dir_struct *dir, Odd, yes? | $ git log -S'Also, we ignore the name ".git" (even if' --follow -- dir.c | commit 453ec4bdf403c2e89892266a0a660c21680d3f9d | Author: Linus Torvalds <torvalds@xxxxxxxx> | Date: Tue May 16 19:02:14 2006 -0700 | | libify git-ls-files directory traversal | | This moves the core directory traversal and filename exclusion logic into | the general git library, making it available for other users directly. [...] | $ git name-rev --tags 453ec4bdf403c2e89892266a0a660c21680d3f9d | 453ec4bdf403c2e89892266a0a660c21680d3f9d tags/v1.4.0-rc1~79^2~8 | $ git diff v1.4.0-rc1~80..v1.4.0-rc1~79 [...] | --- a/update-index.c | +++ b/update-index.c | @@ -120,70 +120,6 @@ static int add_file_to_cache(const char *path) | return 0; | } | | -/* | - * We fundamentally don't like some paths: we don't want | - * dot or dot-dot anywhere, and for obvious reasons don't | - * want to recurse into ".git" either. | - * So much for origins. Starting out, it was easier to ignore all files named .git than just the .git directory. Of course, a lot has changed since then. For example, consider the following: ; git init foo ; cd foo ; mkdir bar ; >bar/.git ; git add . fatal: Invalid gitfile format: bar/.git Adding an abort() to die_routine() and grabbing a back trace from the core dump reveals that this comes from | $ git log -S'if (resolve_gitlink_ref(dirname, "HEAD", sha1) == 0)' -- dir.c | commit 095952585c2a955f45deac69df17a702d7584c80 | Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> | Date: Wed Apr 11 14:49:44 2007 -0700 | | Teach directory traversal about subprojects | | This is the promised cleaned-up version of teaching directory traversal | (ie the "read_directory()" logic) about subprojects. That makes "git add" | understand to add/update subprojects. [...] | $ git name-rev --tags 095952585c2a955f45deac69df17a702d7584c80 | 095952585c2a955f45deac69df17a702d7584c80 tags/v1.5.2-rc0~19^2~9 In other words, if bar is itself a git repository with a valid HEAD, then ‘git add bar’ will register it in the index as a submodule. I should also mention the problem of finding the right git directory: if foo and foo/bar are git trees and you try the following from the foo directory, what should happen? ; git add bar/something How about the following? ; (cd bar && git add something) The answers are less ambiguous with submodules. > The only alternative I see is to compress all the test repos in an > archive and track that - but that's not nice. If the concern is making it pack nicely, you can use an uncompressed tar file for each test (or shar, or whatever your favorite uncompressed format is). Still ugly, but it should work okay. If you can rely on build systems to have git installed, I’d suggest writing a simple script to build the test repository from scratch. You can also try using repositories not named .git if you are careful. I don’t really encourage this. > The reason I don't want to do submodules is that I don't want to > have the submodules as serperate projects as such, because they're > not. they're "test data" so to speak. Yes, makes sense to me. Hope that helps, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html