git – a love/hate relationship (with maybe a little more hate)

As per my previous post on git, we’ve been investigating and running trial repositories using git. So far, though, git has been frustrating me.

Update 2013-10-05: This is a really old post. After an initial skepticism phase, I am now an enthusiastic git fan and I would use it over anything else now. It really is great. I had to let go of a few things but once you do it turns out better than you thought. And nothing is absolutely hidden anyway. All the commands are there to get at what you want. And all the negatives I talked about below have been solved and relatively easily at that.

As per my previous post on git,  we’ve been investigating and running trial repositories using git. A tiny bit of background: we’re a cvs shop and I have a tonne of experience with it and I’m comfortable using it, although not so comfortable I won’t consider other solutions. So far, though, git has been frustrating me, but let me start with the positives.

There are many wins with git but I’ll mention what I feel are its biggest assets: disconnected operation and speed. I would love to get these in cvs, but there are also negatives to git.

The biggest negative for me is the difficulty, if not impossibility, of central enforcement of some rules, that we could easily accomplish in cvs. I don’t like meaningless hashes for tree revisions, but I could live with that.

And why don’t add/commit hooks on the committer-side let me accomplish the same thing as push hooks on the server-side?

Is there a way, when reading file content during pushes, in order to do policy enforcement, to not have to recurse the entire tree and all commits that have ever been done? The reason that’s important is because a committer not using the proper hooks will run into trouble if the server-side git has been using prohibitive hooks the entire time (also remember some functionality appears impossible with add/commit hooks on the committer-side).

For the sake of argument, assume it was just a requirement a typical cvs model was followed in git and you had to do some policy enforcement on the server-side: How can you maintain and enhance server-side hooks and ensure that every user gets those hooks on the committer-side, too. Some have said the committer-side doesn’t need them, they can just fix them at the time of push/pull. I’ve run into prohibitive server-side hooks that require the committer-side to recurse through every commit and fix  the commit message.

These are my hooks so you may say I’m the author of my own trouble but, remember, sometimes in a company you have to have these policies enforced centrally. And, besides, these hooks save us time, trouble and sanity.

And, so, what I found natural and easy to accomplish in cvs, I find difficult and some things, so far, impossible. Maybe it’s because git is opaque compared to cvs. It just seems difficult to accomplish tasks given git’s design and model.

What can I do?

One thought on “git – a love/hate relationship (with maybe a little more hate)”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.