Wednesday, 10 April 2013

Linus gift to the world will be Git not Linux (and what about an OS built on top of an hash-driven file system?)

I know it is a big claim, but I think that Linus Torvalds will be more famous for creating Git than for this work on Linux

Linux is a great example of OpenSource development and a good OS. Its impact is mainly technical and behind the scenes.

Git is a hashed-based file system with built-it version control. Its impact is not only technical but social.

The more I use Git, the more I appreciate its beauty, simplicity and ability to scale while handling complex workflows.

See A must watch TED talk about GIT and democracy for an example of how Git can/will be used to change how information is managed in our society.

Also think about the power of having a 'Git Powered' OS (where all files and actions are Git controlled/tracked). We could finally get a lot of security, resilience, quality assurance and traceable from the multiple software/APIs/Apps that we use/consume.

Git also allows its technical users (like me) to be creative in finding ways to improve their productivity and workflows. See Changing a User’s ExpiryDate from GitHub hosted file or these Git,  GitHub and NGit posts, for examples of the wide range of areas that I have been using git for (in TeamMentor and O2Platform development)

2 comments:

Paco Hope said...

Unlike other version control systems, Git doesn't have much of a security model. Not only does it blindly trust the client to identify itself (in terms of email address, etc), it allows you to rewrite history. (http://git-scm.com/book/ch6-4.html).

One cannot rely on the audit trail supposedly left by Git, because that audit trail can be arbitrarily rewritten. Using it for tracking changes to users' accounts seems dubious.

Dinis Cruz said...

Humm, have you seen that you can sign all commits (http://phreaknerd.wordpress.com/2012/02/09/signing-git-commits-with-your-gpg-key/) , that is not usually done (since the security is enforced by Git Push privileges), but it is there.

Yes you can rewrite history (I have done that a couple times after a mistake) BUT, you can't do it in a way that is not detected. I.e. all new commits (from the non-rewritten versions) will fail. Basically every git commit is hashed with its parents, which means that you can't change the past. This means that the audit trail CANNOT be arbitrarily rewritten.

This is a really robust solution since (as linus says in his Git presentation), based on one hash we can confirm the integrity of the entire history (and the recent git issues were cased by not checking all branches code, which is an edge case)

If you look carefully, you will see that the current strategy is miles better than what happens when the data is stored in databases (with very little, if any, data integrity over time (and for the cases where you can 'replay' the transactions, 'how far back can you go?' and 'are there any hashes for the transaction data?').

Once of the areas I like the most about Git, is how I can easily (and quickly) travel trough time (i.e. get a file system 'view from the past')