Cool Git stuff from CollabNet Potsdam team

During my git trainings I often say that Git is land of freedom, and this is really true. Not many version control system would allow you to change something in history or permanently delete branch or tag. Git some times will prevent you from doing bad stuff, but you can easily say “shut up, I know what I’m doing” just by passing “force” flag (-f). Here I’m thinking about “force push” (aka “history rewrite”) when you can change something in repository history.

Local history rewrite is really useful when you are crafting yours commits. You can easily rearrange them, edit theirs content and commit message by using “rebase interactive”. I’m using this functionality on daily basis and cannot image working without freedom which it gives!

When we are talking about ability to rewrite remote history some people get really scared, especially in large organizations or those that needs to fallow some strict rules like banks and government orgs. From one hand Git and its “SHA-1 checksumming” ensures them that repository wasn’t changed … but from other hand Git allows changing something in past, of curse such change would be quickly spotted and can be fixed. Simple thought about occurrence of such event scares many enterprise companies, especially when they somehow find out about incident in Eclipse Foundation where almost all branches was accidentally deleted.

One of my first tasks in CollabNet was to provides a safety net against force pushes and branch deletion in Git. Our idea was to provide mechanism that could be easily activated and deactivated, will be accessible for regular users and administrators (regular user can resurrect rewritten history and deleted branch, administrators also can do that but also can permanently remove those entries) and protect whole (even deleted and rewritten history) against Git garbage collection. Base on those assumptions we come up with History Protection mechanism. If you want know more about it you can watch our short movie or read my other blog post. There is lots more cool Git Enterprise features coming from my CollabNet’s team in Potsdam 😉

Get a free private Git hosting!

I think that every one knows GitHub and as you should know that we can host there for free ours open source project’s but if we want to have a private repository we should pay for it. It seams fair … but what if I don’t want to pay ? I can setup my own server somewhere or … use one of on-line file hosting service like dropbox (for free we get here 2GB, this is lots of space for git repositories ;)).

How it is possible? It is only about files. As we all know git keeps everything inside .git folder, therefore we can put it in dropbox. To do it we only need to have an account and configured dropbox-folder on ours hard drive, and here is recipe:

First of all we should add new remote to our git remote configuration, I’ll call it dropbox:
git remote add dropbox file:///home/lock/path/to/dropbox-folder/project.git
git remote add dropbox file:///home/lock/path/to/dropbox-folder/project.git
Now we should create folder project.git
Launch a terminal and enter project.git folder
Run:
git init --bare
git init --bare
Go back to yours project directory and push into dropbox:
git push dropbox
git push dropbox

Viola! Dropbox daemon will automatically synchronize with remote “repository”. And there is another feature of this solution, you can share this folder with yours friends!

But there are also some disadvantages:

No access control – if you share yours project with friend she (or he) have full access and can even delete everything … but you always have yours local copy
No web interface – this obvious … I think 😉

This solution I figure out few minutes ago and use it to backup my BS project, and it seams to be working very well 😉

UPDATE:

As Tim said it is also possible to have a free Git hosting on bettercodes.org. To be honest I didn’t check it because solution with dropbox meets my needs.

NEXT UPDATE:

According to Machu’s comment, there is also assembla.com that gives 2GB for SVN or Git repository.

GSoC10 midterm and EGit common ancestor

I don’t know exactly when we hit a Google Summer of Code 2010 midterm date … time runs so fast, few weeks ago I was writing that I’ve got accepted in this year’s program edition, and now we hit a midterm evaluations. This is a quite good time to sum up this short period of time.

Starting from the begging … estimating a project; now I know that initially I was very, very (and even more very, very ;)) optimistic about project time line. According to my initial estimation I should now start working on stashing support in JGit … but for now I’m “stuck” in synchronize view. Even more because now I see that I’ll need two or more weeks to make it ready for 0.9.0 release, now it has two major issues that I would like to solve before upcoming release. I even don’t want to think where I would be right now if Remy didn’t made initial contribution …

OK, so what is project current status? Well we had an synchronize action and it works quite well. It shows upcoming, outgoing and conflicting changes … but there are few issues in current implementation. First of all common ancestor isn’t calculated properly (according to bug: 317371). Next issue is that we always use HEAD as a ‘local’ in three-way-compare, to be honest this seams to be an Team Framework limitation because ‘local’ is always instance of IResource .. btw. I should raise an issue for this ;). Last thing (for now) that in my humble opinion should be included in 0.9.0 is support for change set’s (bug: 3318473) because Git works on repository state changes not on file changes. Additionally there is one small feature that also should be included in 0.9.0: merging support from synchronization view, but (for now) it seams to be a simple thing to achieve.

What are my plans? Fix for bug 317371 currently wait for approvement in Gerrit, so I thing that this is rather a closed thing. For now I’ll focus on change set support. In case of popper handling of source branch setup I’ll wait for any hints on eclipse forum thread, then I thin that I’ll try to implement it somehow. If I fail in this task, I thing that we should disable source branch selecting and set it by default to HEAD.

Some statistics and numbers:

Add preliminary synchronization support within Eclipse for branches. – based on Remy Suen work
32 files changed, 2902 insertions(+), 10 deletions(-)
Refactored UI tests
15 files changed, 434 insertions(+), 393 deletions(-)
Fixes strange result set in Synchronize view on Windows
1 files changed, 26 insertions(+), 19 deletions(-)
Fix NPE when deleting project used in Synchronize View
1 files changed, 14 insertions(+), 8 deletions(-)
Show repository path in Synchronize View
4 files changed, 14 insertions(+), 6 deletions(-)
Simplify API of GitSynchronizeData class.
5 files changed, 33 insertions(+), 72 deletions(-)
Prevent from NullPointerException’s
2 files changed, 24 insertions(+), 8 deletions(-)
Add tests for integration with Synchronize view
13 files changed, 2249 insertions(+), 12 deletions(-)
Fixes obtaining common ancestor in Synchronize view – wait for code review
22 files changed, 1499 insertions(+), 1329 deletions(-)

In my humble opinion this is quite good result for around 7 weeks of work 😉

EGit @ Poznań Eclipse DemoCamp

Yesterday Matthias Sohn, my mentor in Google Sumer of Code, ask me would I like to talk about EGit on Poznan Eclipse DemoCamp. After a moment’s reflection I’ve decided that this a great opportunity for me to get more involved in Eclipse community.

There are not much time for preparation, but I’m not a guy that prefer to have everything fixed, I’m rather prefer to improvise and let thing just happed ;). So I’m plan to have a quick introduction in Git, briefly describe differences between CVS/SVN and Git. Then I’ll move to describe features that we have in EGit 0.8 (that was released yesterday ;)). Last one but not least part would be a live demo covering some day to day use cases, describing how we, our company can benefit from distributed version control system.

btw. This would be my first public speak so I’m feeling stressed … I hope that everything went well during presentation 😉

P.S. I’ll be speaking in Polish of course 😉

Google Summer of Code 2010 … I’m in ;>

Na początku tego roku zastanawiałem się czy wziąć ponownie udział w Google Summer of Code … jak widać po tytule zdecydowałem się wystartować, a nawet mój projekt został zaakceptowany … YEAH! Drugi raz znalazłem się w elitarnym gronie 10001025 studentów z całego świata.

W tegorocznej edycji będę współpracował z Matthias’em Sohn’nem przy rozwoju EGita i JGita (było to do przewidzenia po moich ostatnich wpisach). Dokładniej rzecz ujmując mój projekt obejmuje integrację EGit’a z Synchronization View oraz implementację wsparcja dla schowka (git stash). W tak zwanym między czasie czyli Community Bonding Period chcę zaimplementować UI dla tworzenia tag’ów w EGit’cie, już poczyniłem nawet ku temu pierwsze kroki.

W sumie będzie to dla mnie pewna odmiana w stosunku do Web Developmentu z którym miałem do czynienia do tej pory … zapowiada się ciekawy okres, oj będzie się działo ;> ;D

BTW. W tym roku Wydział Informatyki ZUT ma wyjątkowo wyjątkowo silną reprezentaję. Z moich infromacji wynika, że do SoC zakwalifikowały się jeszcze dwie osoby:

Dariusz Łuksza

Posts Tagged → git

Cool Git stuff from CollabNet Potsdam team

Get a free private Git hosting!

GSoC10 midterm and EGit common ancestor

EGit @ Poznań Eclipse DemoCamp

Google Summer of Code 2010 … I’m in ;>