Why makes it git so hard to use a self signed SSL certificate in conjunction with the https protocol?
At work we have a server for shared git repositories. For some reasons we can’t use the ssh protocoll to acces the repositories so we looked into the git-http-backend. So far so good but we want it encrypted, of course. So we used SSL with our self signed certificate:
git clone https://git.example.com/public
Cloning into 'public'...
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://git.example.com/public/info/refs
fatal: HTTP request failed
Huh? Looking deeper into the problem it turns out that git uses curl for the http(s) transport and curl refuses to work with SSL certificates it cannot verify.
Ok, that’s not a bad thing. To circumvent that you can either set an environment variable (
GIT_SSL_NO_VERIFY=1) to make curl ignore the verification or install the certificate on your machine. The first option is not very attractive on the long term as you’d have to do it on every operation with the remote server, the second one is not very attractive when dealing with multiple developers working on different operating systems. You’ll have to explain to them how to install the certificate on their machine, and that has to be done every time a new developer joins the team, yada, yada.
There is also an option in git (
http.sslverify) you can set where you can tell git to ignore the verification of the SSL certificate for that repository. The thing is you still have to set the environment variable on the first clone and then you have to tell git to permanently ignore this issue for that repository with the configuration option — a lot of stuff to remember. Heck, looking on the interwebs I see may of the people with that problem suggesting to shut of SSL cert verification permanently by setting it globally.
I really wonder why git cannot simply tell the user that the SSL certificate cannot be verified and if you want to accept it permanently, temporarily or not. Every browser does that. Right now it just quits with an error and leaves the user with a cryptic error.
On the other side, when using git with a server providing the repositories via ssh. Git simply asks if you want to accept the key when you access the server for the first time and never bothers you again.
This is freakin’ awesome! It is now possible to checkout from- and commit to git repositories on github with SVN.
This just made my day. This could also mean that this SVN support may later be added into official git (like the CVS emulation), allowing the early movers to use git also on the repository side while staying backwards compatible with the rest who is still using SVN on the client side. Currently it’s more the other way ’round, the wherever SVN is used, git users have to resort to git-svn.
Git bisect, ccache and cowbuilder: a combination made in heaven! Tracking down a commit which introduced an ugly bug with those tools was a breeze.
Git bisect is very useful finding a commit which introduced a bug very quickly, ccache massively reduces compiling time. Compiling icedove (thunderbird) on my laptop using cowbuilder takes roughly 30 minutes. Using cowbuilder with ccache, it only takes 10 minutes, where most of the time is spent setting up the build environment.
… sounds probably like a stupid idea since you could just copy the repository from the old to the new location, but in this case we don’t have direct access to the repositories, only accounts with commit-access. Ahh, and we want to preserve the complete history, of course.
Ok, the plan is to use git-svn to get a copy of the old SVN repository, complete with history and then apply each commit to the new location:
Getting the old repository
git svn clone http://old/repo/
Removing the traces of the old repository
Now we have a git repository containing the complete history of the old SVN repository. That git repository is connected to the old SVN repository via git-svn. In order to commit it to the new repository we have to remove the traces of git-svn:
# Remove the remote branch
git branch -rD git-svn
# Remove the rest
rm -rf .git/svn/
Edit .git/config and remove the
Commiting into the new repository
Now that we can connect our git repository to the new SVN location and commit all the stuff:
# Create the new repository directory if necessary
svn mkdir http://new/repo/
# Init, fetch, rebase and commit:
git svn init http://new/repo
git svn fetch
git rebase git-svn
git svn dcommit
Maybe not the most elegant solution but it works. The new repository contains everything from the old one, only the commit dates are messed up.
how do I push a local git branch to a new svn branch? The other way round is quite easy and well documented but I didn’t find a single document describing what I want to do.
I’m working with an svn repository with standard layout. I use git-svn to be able to use git locally. Until now I’ve always had my master branch reflect the svn’s trunk. For every new feature, I created a local git branch, merged with the master branch when I was done and dcommit’ed it to the svn’s trunk. But now I need to publish an experimental feature which should not yet go into the trunk so I have to publish my local git branch to an svn branch.
git-svn branch foo in the local git branch and it created a svn branch/foo for me but not from the current git branch but from the current master (remote/trunk). That’s of course not what I wanted, I wanted to push the current branch where I’m in and have it linked to the remote svn branch.
Neither the manpage of git-svn nor some documentation in the web helped me. I even found a pretty detailed document which describes each and every aspect of git-svn but unfortunately not mine.
Is this use case so unusual that no one else uses git-svn this way or is it my weak git-FU?