On Sat, 21 Oct 2006, Aaron Bentley wrote: > > Any SCM worth its salt should support that. AIUI, that's not what Tim > wants. He wants to intermix files from different repos in the same > directory. > > i.e. > > project/file-1 > project/file-2 > project/.git-1 > project/.git-2 Ok, that's just insane. It's going to always result in problems (ie some files are going to be considered "untracked" depending on which repository you're looking at right then and there). That said, if you _really_ want this, you can do it. Here's now: # Create insane repository layout mkdir I-am-insane cd I-am-insane # Tell people we want to work with ".git-1" export GIT_DIR=.git-1 git init-db echo "This is file 1 in repo 1" > file-1 git add file-1 git commit -m "Silly commit" # Now we switch repos export GIT_DIR=.git-2 git init-db echo "This is another file in repo 2" > file-2 git add file-2 git commit -m "Silly commit in another repo" and now you literally have two repositories in the same subdirectory, and they don't know about each other, and you can switch your "attention" between them by simply doing export GIT_DIR=.git-1 (or .git-2). Then you can just do "git diff" etc normally, and work in the repo totally ignoring the other one in the same directory structure. Of course, things like "git status" that show untracked files will always then show the "other" repository files as untracked - the two things will really be _totally_ independent, they don't at any point know about each others files, although they can actually _share_ checked-out files if you want to: echo "This is a shared file" > file-shared export GIT_DIR=.git-1 git add file-shared git commit -m "Add shared file to repo 1" export GIT_DIR=.git-2 git add file-shared git commit -m "Add shared file to repo 2" and now if you change that file, both repositories will see it as being changed. INSANE. And probably totally useless. But you can do it. If you really want to. The git directories don't even have to be in the same subdirectory structure. You could have done export GIT_DIR=~/insane-git-setup/dir1 instead, and the git information for that thing would have been put in that subdirectory. Note: the above literally creates two different repositories. You can do the same thing with a single object repository (so that any actual shared data shows up in a shared database) by still using different GIT_DIR variables, but using GIT_OBJECT_DIRECTORY to point to a shared database directory (which again could be anywhere - it could be under ".git-1", or it could be in a separate place in your home directory). Or you could do it even _more_ differently by actually having just a single repository, and having two different branches in that repository, and just tracking them separately: in that case you would keep the same GIT_DIR/GIT_OBJECT_DIRECTORY (or keep them unset, which just means that they default to ".git" and ".git/objects" as normal), and then just switch the "index" file and the HEAD files around. That would mean that to switch from one "view" to the other, you'd do something like export GIT_INDEX_FILE=.git/index1 git symbolic-ref HEAD refs/heads/branch1 to set your view to "branch1". Anyway, I would strongly discourage people from actually doing anything like this. It should _work_, but quite frankly, if you actually want to do this, you have serious mental problems. What's probably much better is to have two separate development repositories, and then perhaps mixing the end _result_ somewhere else. For example, you can use the git checkout-index -a -f --prefix=/usr/shared/result/ in both (separate) repositories, and you'll end up with basically a snapshot of the "union" in /usr/shared/result. (Not that I see why you'd want to do that _either_, but hey, at least you're not going to be _totally_ confused by the end result). Anyway. Git certainly allows you to do some really insane things. The above is just the beginning - it's not even talking about alternate object directories where you can share databases _partially_ between two otherwise totally independent repositories etc. Linus - 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