Why Git sucks?

Yes, this is a rant ;-). But a good will rant. I'm quite aware most people will stop reading after seeing the title, but... If you are interested in knowing current weaknesses of Git - read on.

I would be very happy to be proven wrong here or at least to be shown a working solution in years to come.

Impractical or slow for large and complex repos

For some time now I've been wondering where I should publish my small JavaScript libraries.

How can you do that on SVN?

Simple - just create a repository called e.g. "myJavaScriptLibs" and in that repo you can e.g. have separate directory for each of your libraries.

If someone wishes to join in, they can checkout either the whole repo or any directory (depending on their needs and interests). It's then possible to commit and update without the need to care about other libraries.

Why can't you do that in Git?

In Git, you can checkout neither a single folder nor a file. If you have e.g. 100 plugins, you should have 100 repos. That's the problem PhonegGap has been facing recently. They had to divide repos and it's not clear anymore where the most appropriate one is. There are also performance problems with large repos, especially with large files, but also repos having many files.

Yes, some will say - but this is good - centralization is bad... Well, it depends. If you can spend time to figure out who is who, then it will work for you. You will know who to trust. In practice, however, it's much easier to let central authority keep who-is-who knowledge and download from a single place. That's very important if you work on many projects.

Besides, SVN gives you both - you can have a lot of small repos and a single central one.

Any workaround?

Most people suggest to keep separate projects in separate repos, but that's not a must. With small set of libraries you could use a single repo. And any Git fan will tell you that Git repo is usually smaller than an SVN repo with the same data. But with a lot of libraries you don't need, that's not the same data. So, sadly, but Git is impractical here.

I can't also see any practical solution for a separation of concerns. Some users could e.g. work only on translation and need only to checkout XML files and push them back to the repo. With Git, that would have to be a separate repo.

Problems with internal and external linking

Why linking? For example you have one directory with images and two editions of your app that imports images from a single place. You can also work separately e.g. on some libraries and import them to various projects.

How can you do that on SVN?

Not a wide known fact, but svn:externals can have relative paths also within a single repo! This is very cool. You can even link to a single file. You just commit it and when others update, it just works.

I use this extensively at work. For example, we have a large multimedia project. There is a Flash catalogue that has four editions (full, light and some other variations). There is also a PHP back-end (API), PHP CMS and a C++ module which is actually part of a bigger C++ system. Source mp3, swf and JS files are in a separate directory which is used when working on Flash. Once you commit the changes in a single place, all editions are updated (one source 4 destinations). It's then easy to test the PHP back-end with all the animations, sounds and script ready for work.

This just works, no externals tools (like Jenkins) or hooks (scripts) have to be used. Pure SVN. Simple configuration.

It also just works for branches. Once you make a branch, relative paths simply resolve to a different path in the tree. It's just like you would have relative symbolic links, but built in you versioning system.

Why can't you do that in Git?

From the beginning, lack of externals was one of the biggest problem of Git. This was supposed to be resolved with submodules. Why wasn't it?

The problem is similar to the previous one - you would have to have a separate repository for each directory. If you decide you want to share some directory, you will have to make a repository from it. This is not an easy task if you want to keep its revision history.

I also see no way this would work for branching. You would have to change all your submodules.

Any workaround?

Well, yes, but not without external tools. You could use Jenkins (Java based) or Grunt (JavaScript based). I personally use Jenkins for another project which has a complicated production-release cycle. But this is actually bad! Too much things tend to move outside of the code and you will soon become addicted to yet-another-tool. Someone has to know the tool, update it and know how to fix things...

That can work for you especially because e.g. Jenkins is a very powerful tool. It can do much more than you can do with SVN externals. It will take quite a lot of effort to set up, but will make tedious tasks affordable and make your production-release cycle much more consistent.

So why is Git even used now?

The title is very provocative. I know ;-). I actually know there are some strong use cases of Git.

  1. Use Git when your developers cherish decentralized environment. I think this is the most important advantage of Git, but also probably the most biased one. This is very good, but only for some open source communities. I say some, because I think it's not true for small communities. In such communities people come and go and you just have to have a central authority you can trust. Not all communities have Linus ;-).
  2. Local commits. This one is my favourite for small projects.
    1. You can just work off-line and still be able to push changes and revert if something doesn't work. It's easier to experiment.
    2. You can also break stuff and you will only break them locally until you decide to push things to the repo.
    3. Also, making more and more commits and just one push makes history and future blames nice and readable. And if you work on a project for more than a month, you'll need nice history to know "Why-T-F was this made like that" ;-).
  3. It's easier to merge... a bit. It works better if you know what you are doing. You have to know the cycle of making pull requests which I'm not going to discuss... because it's complicated. Seriously. Diff tools for SVN changed a lot since you first used them. And automatic merging never works when two persons work on the same thing anyway.

All in all - whatever works for you. You just need to know where you are heading and what are the limitations.

P.S. Having said all that github.com/Eccenux ;-)