Posts Tagged ‘Version Control’

ZSH and git branches

I recently stumbled over a nice code snippet for my .zshrc which shows the current branch in a git repository on the right prompt:

git_prompt_info() {
ref=$(git-symbolic-ref HEAD 2> /dev/null) || echo “”
echo ” (${ref#refs/heads/})”

setopt prompt_subst

Inofficial GIT PHP repository – part II

Johannes finally imported the PHP CVS repository into one big GIT repository. This makes working with branches in the PHP repository much easier and you have not to mess around with git-submodules. Thanks a lot for that job.

Inofficial PHP GIT repositories – Importing large trees

A few month ago Johannes Schlüter and I started discussing about GIT and other decentralized version control systems. During our exploration of GIT we thought about importing the PHP CVS tree into git. A few weeks later and a lot of wasted cpu time, we finally managed to provide an inofficial GIT mirror of the PHP CVS repository. It’s provided by Johannes Schlüter and mirrored by me.

Why (not) GIT

People reading my blog (I don’t know if there are some. If you read my blog, just drop me a comment!) must think that I’m somewhat a GIT zealot. Well I like git sometimes and sometimes I hate it by passion. Why I hate it:

/> git
zsh: do you wish to see all 141 possibilities (47 lines)?

Git offers 141 commands, low-level as well as high-level commands (did you ever need git-get-tar-commit-id). I often know that some workflow works in GIT, but I don’t know the exact commands. So I end up asking in #git (at least they are friendly and you get your answer fast). Thats pretty annoying. It’s not straight forward even you use it for a while. I heard that mercurial is better in that way, but at the moment I’m used to git. Well at least I give hg a try managing my debian package for gc-utils.

Use GIT to help you dealing with CVS

A lot of people have to deal with CVS in their companies or in Open Source projects. Therefore they all know an annoying problem:
You are working on a huge change, introducing a complete new authentification mechanism. Therefore you have to touch a lot of classes. In the meantime, other developers have to change also some parts of the code you have to touch, because they have to fix bugs or introduce other features. You cannot commit your stuff into the CVS everyday until it’s finished as it would break the codebase and nodody would be able to compile the code anymore. So you just wait until you are finished. In that 7days of coding you don’t do any commit, but a lot of code was changed by others! So if you try to commit, you get a huge list of conflicts. It’s really a mess! Let’s drop that, and do it nice using GIT.

Import the CVS HEAD into the master branch of your cvs repository using gc-utils.

gc-import myProj
cd myProj

Now, create your own branch. We will call it exp. In that branch you will introduce your new breaking-trough feature.

git checkout -b exp master

Let’s start coding your new authentification mechanism. Just use your standard workflow. Change, commit, change, commit. Meanwhile, track the changes from the repository by switching back into the master branch and run gc-update. Your personal branch than keeps up-to-date with the CVS head and you can adopt your feature to API changes made in the CVS head.

// edit …myfanynewauth
// commit
// edit
// commit
git checkout master
git checkout exp
git merge master

After you finished introducing your new superb feature, just do a merge back from your personal branch (exp) back into the branch that tracks CVS by merging exp with master. You don’t have to do this step, You just can pick up your changes from exp directly and commit it if you want, because you are allready up-to-date with CVS due to your merge from master (see code above).

git checkout master
git merge exp
git log // pickup your changes
gc-commit -c a2334bc fe2346ab ….

GIT helps you to do things a little bit easier. You can commit, revert and diff every change during your developement and nobody recognize it, as it is just in GIT not in CVS.

Another example
Assuming your CVS HEAD is broken, just import it into your git. Go back to the version that worked and then branch and work in your personal branch.

gc-import myProj

Then checkout the version that worked

git log
// perfect, version a42bba seems to work
git checkout -b working a42bba

Start working on your branch. After you finished your work just merge it back into the master branch which tracks your CVS.

git checkout master
git merge working
// search for your personal commits
gc-commit -c faab346 ab56dd2e ….

GIT in companies

CVS is probably the most used version control system. A lot of companies and open source projects use it daily. In fact most of the companies prefer to switch over to subversion instead of an decentralized VCS like GIT or mercurial.
Why? They often argue in that way

  • I don’t want to have all the logs/revision on every PC of every developer, it’s not safe enough. Well this is obviously not a good reason. Just run git-cvsimport once and you have everthing from the CVS in your repository.
  • They want to use CVS/SVN as a backup service too. Same here, usually companies work with a central repository. You can do this in GIT and Mecruial too, by using a shared repository where everybody pushs into. Even better, you can just allow the project manager or the security officer to push changes. Therefore he is responsable for broken commits in the shared repository. Therefore he’ll make sure that every commit is good enough, which helps you to improve quality of your software.
  • DVCS are different from centralized VCS. It’s too hard to migrate and to have trainings for your employees. Thats probably a good arguments. Git is not easy to deal with. Mercurial seems to be much easier, but it’s not 100% the workflow like an centralized VCS. So it’s easier to switch over to subversion

GIT Cloning of branches

GIT is pretty powerful. I use it on a daily base at the moment. Furthermore I watch the mailinglist. Therefore I discovered a simple workflow that is not yet implemented nicely in GIT: cloning of a particular branches.

I wanted to clone the cvs-imported PHP_5_3 branch of PHP, which is provided by Johannes Schlüter. But at the moment git-clone just supports cloning of complete repositories. So I asked myself how do clone just a certain branch. At the same time somebody came up with a similar issue at the git mailinglist. Linus came up with a simple batch of commands (git-remote, etc) to be executed to get the result.

I finally decided to write a small script which does this job, supporting multiple branches to be cloned from a certain repository. (more…)

Git vs. Mercurial

After using CVS and SVN for years now, I finally stumbled over distributed version control systems (DVCS). Beside the commercial BitKeeper there are various Open Source projects around. The most famous is probably GIT which was initially developed by Linus Torvalds and is now maintained by Junio C. Hamano. An other approach is Mercurial which started in the same time when GIT started. There are several other (bazaar, monoton), but I’ll focus on these. The systems have some concepts in common but differ at some point. I don’t want to give you a deep introduction to the DVCS approach, there are enough tutorials around that cover this topic well.