Category: DVCS

Using git behind a proxy

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.

git question

Ok, I’m not really git fan. Actually, I don’t like at all… But I have to use because of some projects and now, that GNOME is moving to Git, more.

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 🙂

Why just one DVCS?

There are a lots of flame wars out there about the best DVCS (Distributed version control system), like others (IMHO) ego wars (KDE vs GNOME, VIM vs EMACS, etc). There are very good options like git, mercurial, bazaar or darcs and many people (as GNOME is doing right now with all the survey thing).

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? :-P) 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 🙂

Mercurial 1.1 is out

2 day ago was released the last version of Mercurial (HG). The changes look great 🙂

Some changes:

General:

  • Added ‘resolve’ command for better tracking of in-progress merges
  • Several speedups for status and diff commands (especially on Windows)
  • Some modules have been rewritten in C for greater speed
  • Compatibility with Python 2.6 2
  • Add some buffering to the templater
  • Better documentation on git diffs

    Web interface:

    • Add a canvas-based repository graph
    • New and improved hgweb themes: paper, coal and monoblue
    • paper is now the new default style; the old default is now called ‘spartan’
    • Better WSGI compliance
    • Collections now show nested repos (best used without a checkout)
    • diffs are more sensible, follow diff.git settings
    • Better alternative for repository collections

      Commands:

      • resolve: new command to help keep track of merges
      • merge: only implicitly select same-branch heads
      • export: append instead of overwrite when exporting multiple changesets
      • bundle: added support for different compression types
      • rollback: clean up empty files
      • tag: without a checkout, use tip as the tagging revision’s parent
      • log: allow searching by user (with -u)

        Extensions:

        • rebase: new extension to support rebasing changesets
        • bookmarks: new extension to provide (local-only) git-like branches
        • zeroconf: new extension to support publishing repositories through Zeroconf/Bonjour
        • convert: added support for conversion from bzr repositories
        • color:
          • add colorization of diffs
          • add –color options to many commands
        • bugzilla: added support for Bugzilla 3.0

        See the full Release Notes for more info.

        BTW, we’ve just created a public personal (and for groups and free software projects) mercurial repositories at Emergya (at last!) 🙂

        Here mine with some silly repos:

        http://hg.emergya.info/~jojeda

        Enjoy! 😉

        Creative Commons Attribution-ShareAlike 3.0 España
        This work by Juanje Ojeda is licensed under a Creative Commons Attribution-ShareAlike 3.0 España.