I\'m developing an application that uses git, so I need to test its integration with git. Inside my git repository, I need to have another repository (my_git_repo/tests/anot
I loved @hvd's reply and I think it should be an answer that deserves voting up:
You could include an already set up sub-repository as a zip file -- or whatever other format you prefer -- and then make your test create or clear a directory and simply unzip the sub-repository there. That said, while it greatly reduces the complexity of running the tests, it greatly increases the complexity of creating and maintaining the tests, so it's not something I recommend.
There are situations sub-modules are just too complex for a simple issue. My code was already working with the setup similar to the original question. My problem was involving test repos where those repos (3 of them) were going to be used for testing purposes only using actual repos with known commits. So I wanted to add those repos into git just like any other subfolder without the complexity of submodules... this is for testing for crying out loud. I needed the histories to be within those test repos. I noticed that the complexity of submodules is actually greater than the said 'complexity of creating and maintaining the tests'... actually it's simple.
const GitMockReposWD = Path.resolve(__dirname, 'mocks/git')
before(`Decompress git mock repos...`, function (done) {
if (!Fs.existsSync(GitMockReposWD)) {
console.log(`Decompressing git mock repos...`)
const Decompress = require('decompress')
Decompress(Path.resolve(__dirname, 'mocks/git-mock-repos.zip'), GitMockReposWD).then(() => {
console.log('Done decompressing!')
done()
})
} else {
console.log(`git mock repos already exist...`)
done()
}
})
after(`Clean git mock repos...`, function () {
if (Fs.existsSync(GitMockReposWD)) {
console.log(`Cleaning git mock repos...`);
Fs.rmdir(GitMockReposWD, () => {
console.log(`Done cleaning git mock repos!`)
})
}
})
The above code simply decompresses the test repos before the tests suites are run and cleans them up afterwards. The idea here is to setup the repos as required by your scenario and then add them to an archive. If there are any changes to the repos then you just update the archive.
You could transform your nested repository into a bare repo. A bare repository can be committed inside another repository.
One way (more here) to transform a repository into a bare repository:
git clone --bare test-repo
cd test-repo.git # directory created by previous command
git remote rm origin # to remove the pointer to your original repo
Now, test-repo.git
can be committed inside your main repository. If, at some point, you'd like to make edits in your test repository (edit files, add commits) you can just clone it back into a non-bare repo (git clone test-repo.git
).
Submodules don't necessarily need to be cloned separately; you can publish a project and its submodules in a single repo. Just have a branch dedicated to the submodule contents in your main repo, then after cloning the main repo git clone -sb
the submodule directly from there.
# setup your current repo this way:
( git init sub
cd sub
> file
git add .
git commit -m-
git remote add origin ..
git push -u origin master:sub/master
)
Setup in new clone:
git branch -t sub/master origin/sub/master
git clone -sb sub/master . sub
and sub
will have the most recent content.
git rev-parse :sub
will show you what's committed for sub
-- i.e. what should be checked out there -- when you don't just want the current branch tip.
You could hook up the git submodule
command here, with a .gitmodules
file and this and that, but it hardly seems worth it.