The Spectre of Math

February 27, 2010

another reason why I hate git

Filed under: Hacking,Linux,Technology — jlebl @ 11:04 pm

So with git, I have to commit before pulling latest changes. OK, why is this braindead: I generally just go to my source tree and start hacking. At some point I want to commit so I think “hey … maybe someone did something else” so I do git pull and git yells at me. I have to do a commit. Well, if I do a commit and the changelog has changed, then the next pull will automatically will have a conflict to resolve. This means SEVERAL extra unnecessary steps simply to commit something that doesn’t have any a-priory conflict with any other commits other people did.

I am sure git is great for people who want to spend their days playing with git. But it sucks if you simply want to code. Oh CVS, where are you?! CVS also has lots of braindamage, but the braindamage only makes you work hard in exceptional situations. Git does things “correctly” apparently, but to do so, it makes you work harder in every situation.



  1. CVS’s handling of binary data was completely and utterly worth the move to SVN. Uggh, not doing diffs on binary data just sucked. SVN is pretty much a cleaned up version of CVS. Command structure was designed from CVS and it has always just been a modernized version of CVS. If git really makes you commit before pulling, that seems brain dead. Can you just commit locally and update from the remote?

    Comment by Doug — March 13, 2010 @ 1:28 am | Reply

    • That’s the whole point. You need to commit locally before pulling changes from the repository. That means that if you maintain a changelog it will force you to have a conflict in the changelog (Because you presumably update changelog on committing). I suppose you could commit without changelog, pull, write changelog, commit, push. All the few milliseconds I saved on the operations being local I just wasted (and then some) on doing two more extra operations.

      Yeah, I was happy with SVN. Not sure if it’s worth the pain to change if CVS already works, but at least you are not changing to anything braindead.

      Comment by jlebl — March 13, 2010 @ 6:14 am | Reply

  2. If you want to see if anybody has done stuff, just do git fetch ; git log master..origin/master

    Comment by Justin — August 22, 2010 @ 3:02 am | Reply

    • it’s just much easier with cvs is my point. Yes, I know you can do everything with git that you can do with cvs. My point is that it’s more complicated, git is doing way too much magic, I have to really really think about where my changes live currently (there are far more states that my changes can be in) and I live in perpetual fear that I’ll screw it up. With cvs it’s hard to screw up since it doesn’t do that much. The mental picture for cvs is FAR simpler and it does everything I’d ever want … so why change?

      Comment by jlebl — August 22, 2010 @ 6:19 am | Reply

  3. Also, SVN updating and deciding to automerging your stuff can be bad and cause pain, too.

    Comment by Justin — August 22, 2010 @ 3:03 am | Reply

  4. You can also use git stash. Sorry, but personally I prefer stashing before a pull to SVN’s braindead merging. With git i can even commit only a part of the changes I have made to a file, stashing the other parts away. And then there is nothing like not having to commit to a central repository with undone work just to have a history that I can rollback.

    Comment by ashwoods — October 11, 2011 @ 6:14 pm | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: