Tag: git

Tracker website and (another) git workflow

June 3, 2009 / / 3 Comments

Tracker is under a massive refactoring phase for the release of the 0.7.x series and there is a lot of work carried out. So to catch up and to give better info we started to work on the website to update the info over there.

Look at our new shiny development page where you can find the details and how to install tracker from the source with all the packages that you need in a debian based distro. BTW if you know what you have to install in Fedora and friends just let us know and we are going to add them in no time.

Anyway, I started this post to highlight another hint on how to use git (and where to find later when I will forget…)

The good news is Tshepang stated to contribute to the tracker website (source tracker website – if you feel like patches are always welcomed and yes you have to download all the gnomeweb-wml module).

Before today I always used git as a stand alone developer, but now I had to figure out how to track the changes in the master form the other projects, without losing all my work and the patches.

So here is the solution of this riddle.

From the master create your own branch

git checkout -b WIP

apply the patch and work on the branch

git am 0001-super_patch.patch

hack hack hack

git commit -am "A lot of good stuff"

Now you ready to go. You want to put back your changes in the master and then push on the server.

How to do that?

You must rebase your local Work In Progress branch with the local master that track the remote master. eh? yeah. Let’s go through the command:

git checkout master #Back in master

git pull # Grab all the new updates

git checkout WIP # Back in WIP

git rebase master #The Black magic. Commit all you change on top of the master ones

and now you good to go:

git checkout master # Back in master
git merge WIP # It’s gonna be a fast foward merge so no commit message will be created; that is exactly what you want, because the meaningful commits’ messages are in the WIP branch and a commit with the message “merged WIP” is not that interesting.

git push # And we go online. 🙂

On a side note:
gitg is your friend.

gitg screenshot

gitg screenshot

Git Again – Svn Workflow

April 15, 2009 / / 0 Comments

On this page on the GNOME website I found how to use git properly if you are using it as a gateway to a svn:

  1. git svn clone _svn_server_location #Clone the repository
  2. git svn fetch #Download the stuff
  3. git svn rebase #Merge the updates with the current
  4. git checkout -b myfeature #Create a local branch
  5. hack hack hack # hack
  6. git commit -am "changed stuff" # Commit
  7. hack hack hack # hack
  8. git commit -am "changed other stuff" # Commit
  9. git checkout master # Change to master branch
  10. git merge --squash myfeauture #Merge myfeature to master
  11. git commit -am "merge the feature to the master"
  12. git svn dcommit # Commit everything on the svn server

More info about git in the previous posts

Some stuff about git you should know

April 10, 2009 / / 3 Comments

Git rocks, and after two days of using I can confirm it.

I was a user of bazar, but with the switching of GNOME to git and the big trouble that bazar was giving me to commit on the svn of the EBI I decided to give to git a go.

Also on bioinfoblog the match between git and bazar it’s a though one, but I right now the svn support from git just works out of the box, so I started to use it.

I want also to point out that with the last git (ATMOW) is possible to create a remote branch on the svn server with:

git svn branch mybranch

and this was one of the killer feature that made me switch.

This is not a tutorial on git but I will provide you some quick and dirty pointers to other posts that I found interesting for a quick introduction to git.

Stuff to keep in mind about git:

  • You always work in a local branch.
  • You commit locally
  • You push (or dcommit if using a remote svn repository) to the remote branch.
  • The name of a remote branch is remote/foobar and you need to put the remote prefix also if it doesn’t show up with the remote prefix not optional. You need this if you create a local branch and you want to track a remote branch.

Some pointers here:

I’ve customized my bash prompt to show my current branch on a git repository. This is the code (based on some code found on the net that I can’t track anymore.. I’m sorry….) looks like this:

#git branch
parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* (.*)/(1)/'
}
#grey
PS1='[33[0;32m]u[33[1;32m]@[33[0;32m]h[33[00m]:[33[01;34m]W[33[1;30m]$(parse_git_branch)[33[00m]$ '

The terminal looks like this
git prompt

Cercando di capire qualcosa su GIT

September 25, 2007 / / 0 Comments

Siccome non ho ancora utilizzato git seriamente e sto cercando tuttavia di farmene un’idea vi dò un paio di lin interessanti:

  1. Il workflow che dovrebbe essere utilizzato per git
  2. giggle, Un simpatico programma grafico per tenere git sotto controllo senza impazzire.
  3. Un utilissima introduzione a git con un crash course che compara svn con git.
  4. La home page di git.

Tre cose che ho capito:

  • ho sentito il bisogno di fare un commit di tipo locale e non portarlo su svn. Scrivere perché e cosa. git poteva risolvere il mio problema.
  • git funziona male su windows e bene su linux. E chi se nefrega direte voi. Bhè, anche io. Windows non lo utilizzo.
  • git ho la capacità di poter portare tutto il lavoro che fate su subversion. Quindi questo non rompe la compatibilità con i vari svn che abbiamo in giro.( e ne abbiamo vagoni…)

Sarà git la soluzione a tutti i nostri problemi? No. saranno i neutrini. Rimango anche abbastanza preoccupato dell’aumento dell’entropia.