Multiple git configurations depending on the repository path

For my work on Debian, i want to use my debian.org email address, while for my personal projects i want to use my gmail.com address.

One way to change the user.email git config value is to git config --local in every repo, but that's tedious, error-prone and doesn't scale very well with many repositories (and the chances to forget to set the right one on a new repo are ~100%).

The solution is to use the git-config ability to include extra configuration files, based on the repo path, by using includeIf:

Content of ~/.gitconfig:

[user]
    name = Sandro Tosi
    email = <personal.address>@gmail.com

[includeIf "gitdir:~/deb/"]
    path = ~/.gitconfig-deb

Every time the git path is in ~/deb/ (which is where i have all Debian repos) the file ~/.gitconfig-deb will be included; its content:

[user]
    email = morph@debian.org

That results in my personal address being used on all repos not part of Debian, where i use my Debian email address. This approach can be extended to every other git configuration values.

Migrate a Git repo to a SVN one

We often see the opposite, convert a SVN repository into a Git one and try the breeze of a DVCS, but what if you want to convert a Git repo into a SVN one?

The process is not easy (and you need a "straight" Git repo: no merge, too complex branches and so), and the result is quite raw, but you're still able to convert the main part into SVN. Here are the steps:

1. create an empty SVN repository: svn mkdir svn://path/to/repo/project/{trunk,branches,tags}
2. clone it in a Git repo: git svn clone svn://path/to/repo/project --stdlayout . This will create a project directory, empty except for the .git information directory; master is the default Git branch created by git-svn that maps SVN trunk.
3. cd project
4. add the original Git repo as a remote: git remote add origin git://uri/to/git/repo/project.git
5. fetch from it: git fetch origin
6. create a local branch for the remote master: git checkout -b old_master origin/master . Note that master branch is already present, so we define another one.
7. being on old_master we rebase this branch onto master: git rebase --onto master --root . Doing this, we have "moved" all our commits from old_master to master
8. and push all the commits into the SVN repo: git svn dcommit

It's not that elegant, but it gets it done. I'd like to know if someone is aware of a better method, also to import tags and branches, that this process doesn't do.

UPDATE: added 'cd project' step 2

git push -> rejected?

I'm still not that used to git, but I'm trying to use it as much as I can, and so suddenly I crashed against this:

$ git push
To git+ssh://...
! [rejected] summary -> summary (non-fast forward)
error: failed to push some refs to 'git+ssh://...'

Mh, "not-fast forward" what? am I playing a song? well, after all, I didn't do anything strange (I suppose):

• was on master
• branched out a feature branch
• did some commits on master and some commits on the branch
• rebase the branch on master

all (except rebase) from a couple of machines on the same repo.

Well, after a bit of panic, I googled and found not to worry: did another pull

$ git pull
Merge made by recursive.

then push went pretty good:

$ git push
...
To git+ssh://...
6f6324d..f39911e HEAD -> summary

Chain scripts execution in git hooks

The common git hook is something like:

#!/bin/sh

exec "another script"

and since "exec" replace the current script with the other one, only one command can be execute in a hook. Even more, the common hook takes input from the standard input, so the first command takes it, and the second?

The real situation was reportbug post-receive hook, that looked like:

#!/bin/sh

exec /usr/local/bin/git-commit-notice

but I wanted to add seanius' tagpending hook to it. The solution I found was:

#!/bin/sh

# to save stdin on a file to pass to both scripts
cat > post-receive_tmpfile

/usr/local/bin/git-commit-notice < post-receive_tmpfile
/git/reportbug/reportbug.git/hooks/git-post-receive-url-notifications.py < post-receive_tmpfile

rm post-receive_tmpfile

that saves the stdin to a file, passed again to both the scripts.

Of course, I'd be happy to hear more elegant solutions :)