I have nested git repos, will it cause a problem

git

A history

I installed etckeeper
I decided to track e.g. shorewall firewall configuration as its own git repository. I think I wanted it to be easier to look at specific configuration changes. I decided I did not need etckeeper any more and uninstalled it. So no conflict, except…
While re-considering etckeeper, I notice I didn't actually remove /etc/.git.

Before I realized, I would have thought that git init would refuse to create a nested git repository.

If I simply resumed using etckeeper, I'd be concerned that the outer git could get bloated tracking the inner .git directories. Alternatively, it might ignore all the files in the directories which are separate git repositories.

So I'm curious, what could possibly go wrong?

Best Answer

My first tests with nested git repositories didn't suffer any of those three problems. You don't have to add .git in gitignore; the contents of all .git directories are ignored automatically.

The other files (e.g. in the same directory as .git) can be committed in the outer repository.

So I thought etckeeper could keep tracking all files, while sub-directories could have their history recorded more carefully in specific repositories. The two histories wouldn't know anything about each other.

I only noticed a problem later. When I committed a directory which is a git repository and contains commits itself, and I hadn't already committed files from that directory in the outer repository, then it appears as a Subproject. The contents are represented only by a commit ID. gitk seems to show it as a Submodule instead.

This sounds like git really wants to recognize them as git-submodule. I don't particularly understand git-submodule, I just know it has a reputation for being a bit confusing.

I also noticed the .etckeeper file bloats up with files from the .git directories, even if git is using submodules.

Related Solutions

Shell – Get git branch from several folders/repos

Try this. $1 should be the parent dir containing all of your repositories (or use "." for the current dir):

#!/bin/bash

function git_branches()
{
    if [[ -z "$1" ]]; then
        echo "Usage: $FUNCNAME <dir>" >&2
        return 1
    fi

    if [[ ! -d "$1" ]]; then
        echo "Invalid dir specified: '${1}'"
        return 1
    fi

    # Subshell so we don't end up in a different dir than where we started.
    (
        cd "$1"
        for sub in *; do
            [[ -d "${sub}/.git" ]] || continue
            echo "$sub [$(cd "$sub"; git  branch | grep '^\*' | cut -d' ' -f2)]"
        done
    )
}

You can make this its own script (but replace $FUNCNAME with $0), or keep it inside a function and use it in your scripts.

How to set up username and passwords for different git repos

Using SSH

The common approach for handling git authentication is to delegate it to SSH. Typically you set your SSH public key in the remote repository (e.g. on GitHub), and then you use that whenever you need to authenticate. You can use a key agent of course, either handled by your desktop environment or manually with ssh-agent and ssh-add.

To avoid having to specify the username, you can configure that in SSH too, in ~/.ssh/config; for example I have

Host git.opendaylight.org
  User skitt

and then I can clone using

git clone ssh://git.opendaylight.org:29418/aaa

(note the absence of a username there).

Using `gitcredentials`

If the SSH approach doesn't apply (e.g. you're using a repository accessed over HTTPS), git does have its own way of handling credentials, using gitcredentials (and typically git-credential-store). You specify your username using

git config credential.${remote}.username yourusername

and the credential helper using

git config credential.helper store

(specify --global if you want to use this setup everywhere).

Then the first time you access a repository, git will ask for your password, and it will be stored (by default in ~/.git-credentials). Subsequent accesses to the repository will use the stored password instead of asking you.