This is a simple recipe about how to use git behind a proxy.

Right now I’m working behind a very restrictive firewall and I can’t get any port I need open, so I use a proxy socks for working with git,bzr,jabber and so on. I was looking for an easy way to use git with a proxy but I didn’t find easily the solution. After some researches a friend (Roberto) found the solution and we use it at work.

Let’s see it

Just in case we don’t have it:

$ mkdir ~/bin

Now the interesting part, the wrapper for the proxy:

$ cat <<EOF>> ~/bin/proxy-wrapper
#!/bin/sh
# Put your own values
PROXY_IP=10.0.0.80
PROXY_PORT=22000

nc -x${PROXY_IP}:${PROXY_PORT} -X5 $*

EOF
$ chmod +x ~/bin/proxy-wrapper

Note that you’ll need to have installed netcat (the openbsd’s one: netcat-openbsd) to be able to use the command nc with the option -x.

Then you’ll have to be sure you have setted the ~/bin directory on your PATH and then add the env variable GIT_PROXY_COMMAND. That variable will be used by git for doing pushes through git or ssh protocol:

$ cat <<EOF>> ~/.bashrc
export PATH=~/bin:"${PATH}"
export GIT_PROXY_COMMAND=~/bin/proxy-wrapper
EOF

Now you will be able to use git normally with no worries about the firewall, nat or whatever.

Anyway, I use it. But there are some workflows I don’t get well yet. I know the basis and maybe a bit more, but I’m far from a git-poweruser.

There are some docs and interesting threads about git in GNOME, but I have to learn a lot…

The thing is I like to collaborate with some project in which official git repos I haven’t account, so I try to use Github to public and manage my branches.

Although I don’t like git so much, I do like Github. It is a very good web gui for a DCVS and has awesome features…

But here is one of my use cases:

I try to make some changes on a Debian project (live-helper) which uses a git repository. But I work with a friend on some features and changes over the main project.

My first though was: I create a mirror of the upstream project on Guthub, my friend create a “fork” (kind of “git clone” but keeping parent-child relationship on Github) and then he can make so many branches he need and develop the different features and changes.

I like to have one branch where merge all the mature features, but also keeping the upstream mirror. So I create a branch of my mirror and I’m merging there the different features.

I think until here everything is right. If there is a better way, tell me, please.

Keep going… The problem is not all the features are interesting for the upstream projects, so the merged branch is not good place for get patches or merge from. But it is our good branch which we use for our project, so we need keep as is.

But some of our features are integrated in upstream. Which is good and thing we want. The problem is we we pull the changes from upstream, there are some changes identical, but merged or committed in other order. Some times pull a changed we push to upstream make some mess in our history…

And if we like to keep updated the different feature branches from upstream to keep working on this features but with valid and new code, from where we pull those changes?

From our mirror? the merged branch? is there another magic git way?

I know this could be very confusing. I think it’s easy to explain with graphics but my artistic skills are below zero…

But this graph could help (or not…)

I hope some git guru understand some of this uses case and give me some tips to doing better.

BTW, I couldn’t find a way to make more than one fork from one branch on Github, which would have been useful…

NOTE: I have my reasons to dislike git, but it’s now the point of this post. I don’t like flames and I don’t like argue about which DCVS is better, I just like to know how to use better this tool. Thanks

Even in my company, we were (actually, we’re already) discussing about the right one for our day by day at work. We’re almost sure to adopt a good dvcs is better than our well known Subversion, but we don’t know the best option.

We could follow the typical technical reasons people usually does, but we must also pay attention to other (more practical) reason. For example, we develop linux distributions (mostly) based on Ubuntu, so that tell us we should use bazaar to make easy clones, branches, merges and any kind of tasks in order to collaborate.

But, in other hand, we work with rails. Rails and projects around use git intensively, so makes sense to use git as well.

And we also work with other projects which still use subversion or even others systems.

After think about the best possibility it’s clear for me that choose just one makes no sense at all. We can choose one for working internally, but we’ll still have to deal with with other system we work or collaborate with.

Our major project is the technical level and background of the people here is very heterogeneous. We got very geek guys and people who just got out from the university and don’t know to much about real life tools…

So, we need something with learning curve small enough to normal people could just use the dvcs and good enough to use in professional projects.

But I really think the best way, at last, is to learn the basics of each one (of the most common ones), use internally just a good one, but bring to the people the way to use whatever they want or need for each project. I think John is right about that… why to choose for the people? Let’s people decide by themselves.

I was talking with Alberto about this and we agree (didn’t we? ) that to have a kind of interface which makes abstraction about which dvcs is below and gives us compatibility between them, probably is better than try to push people to one or another system just because we think is the best.

There ar to much big (and little ones) projects which have already chosen git, bazaar, mercurial or other and are very happy with their decision to just change because someone say so…

I don’t think to expect that is very realistic…

I know this is possible and we as open source and free software people doing all the time: make open standards, communication APIs, and abstractions layers. I don’t see more complex than a lot of projects (GNOME itself) does al the time.

I think I will sum myself to the John’s count he is meaning to do something similar