Friday, 29 May 2009

Why Not To Git

The header of my previous post was a lame joke that nobody else got, I admit...

Anyways, there are also reasons why git is not the best choice and these come down to one (or two, depending on how you look at it) reason: complexity. Distributed version control systems are a different scheme to start with and git doesn't make an attempt to make it any easier to understand.

There's also the problem of security in the more common way, rather than way where git excels. I'll discuss this point in this post and maybe delve into usability and ease of learning leater.

In the modern time companies are out-sourcing development to off-shore companies and in these cases it's usually desirable that not everyone gets access to everything. There are no in-built mechanisms to control access in git, by default everyone can access everything in a repository. The idea as far as I can tell is to create small repositories so that we can give access to entire repositories to people. This is quite awkward in practice. And since git doesn't deal with single files but commits which can include several files at a time fixing this is not simply a case of forbidding access to some files for some people. Imagine if we have two files and two developers. One of them has access to both, the other only to one file. Developer one changes both files and commits. What happens when developer two tries to pull? We would have an incomplete repository (very much against the whole idea of distributed vcs's) and furthermore the SHA calculation would fail (?).

I can only think of one way this can be solved in git's model. That is to use encryption on files where the user doesn't have access. But this would also require that the entire access set is delivered with the repository. Possibly this would also require the inclusion of public keys into the repository and it would definitely need access to the server where the company's key is. Crypting and decrypting these files would make repository cloning a lot slower especially if there are lots of files with access sets (which often is the case).

So it might well be that this is something where git will never be good at forcing companies to either use other vcs's or building complicated work-arounds. But it is very common practice that access is restricted. For instance in a large system you might not want to give every design document to everyone, only what is needed for them to do their work. But if every part is in a different repository, building the system would be difficult and people who needed access to everything (like architects) would find this awkward. The practical solution would be built a middle-layer that automatically updates some repository which holds all this info and where only select people have access, but this would require a lot more work to build and maintain.

I believe this is not something Linus and the guys had in mind since withholding information goes against FOSS, but in reality not every company can afford to give out everything. Otherwise some Chinese company will push them out of business with their version.

No comments:

Post a Comment