The Spectre of Math

August 31, 2010

damn git again

Filed under: Hacking,Linux — jlebl @ 5:42 am

Bitten again … so I now finally noticed that it seems that a ChangeLog file is now out of favour in the GNOME git. People just commit stuff (translations it seems) without anything. Plus when i do git pull, it just spits out a lot of jargon nonsense but doesn’t tell me the important things: Which files have changes. So I don’t actually notice what was changed. I have to go hunt down that information.


Even the git browser at is useless. I wish I had CVS back.



  1. Relax. It’s not that bad.

    The trick is to avoid git pull. Assuming you have a remote called “origin” and a branch called master that is tracking it, try this:

    git fetch origin
    git log master…origin/master

    You can use the -p option on log to see the diffs as well.

    If all is well, then just merge:

    git checkout master
    git merge origin/master

    Git pull does both the fetch and merge together. This works if you’re pulling into a separate branch, so you have something left over to compare it with. But if you’re just tracking a remote repository, and not working much in your own branches, you probably just have a master and an origin. So just split up the fetch and merge steps, and you’re fine.

    Good luck,
    – Chris

    Comment by Chris — August 31, 2010 @ 5:45 pm | Reply

    • but but … my point is that git is unnecessarily complex and spews garbage information at you instead of what you want to know. I am simply ranting. I understand that you can do with git everything that you can do with cvs (or svn). But it’s so unnecessarily complex. I feel like I am calling a neurosurgeon and an ambulance to put on a band aid.

      I fully expect that when I was 20 I would have loved git. But my priorities have changed where I don’t care about how the repository works. It is just a repository. The priority is the code that I hack on. I have realized that simplicity is FAR FAR superior to having every possible feature. GNOME was just fine on cvs 10 years ago when internet connectivity was much worse and a distributed system would have had more appeal. In fact, I feel far better with CVS since it is far easier to understand what it does and it has very few bugs (if it’s documented it’s not a bug). It is much harder to screw up your repository with cvs than it is with git.

      Having seen the clusterfuck that results from having lots of branches on a project with many people I don’t see the need to have more than 1-2 branches anyway. I have a feeling lots of random bugs could be avoided if people worked on a single branch and all merging was done by hand (inspecting/editting patches, running patch).

      Comment by jlebl — August 31, 2010 @ 6:56 pm | Reply

      • I think it’s pretty easy to mess up a CVS repo as well. And I wouldn’t hold CVS up as a prime example of user-friendliness. Somehow being tethered to a network connection in order to fetch log history and so on seems a much bigger drawback than splitting fetch and merge.

        I realize you’re ranting, though. It sounds like you’ve been “forced” to change tools by external means, rather than coming to git naturally. So you’re taking out your frustration on git instead of the people who forced the change.

        Basically, it sounds like a personal problem, not a technical one. I can understand that too. I’d be upset if mercurial had won the SCM wars instead of git. 🙂

        Git does have a cvs server interface though. Perhaps you can setup a cron job that uses git to mirror the repos locally, and you can use CVS as your main interface.

        It might be easier just to script your own ‘pull’ command though. Simplicity can be scripted if you have the right low level tools.

        Comment by Chris — August 31, 2010 @ 7:28 pm

      • Oh, and I agree on the merging. I think git works best with the “benevolent dictator” model, where there is one tree that all branches must flow into at some point.

        Comment by Chris — August 31, 2010 @ 7:39 pm

      • Well I guess a personal rant is part of it. But partly it is a general rant about git itself. Also it is not just splitting fetch and merge. I find that the whole idea of DVCS is overly complicated. Git just seems to make the whole experience a bit more unpleasant and yet more complicated. To use git you must have a far more complicated mental image in your head. If I only use the GNOME git repo about once in 3 months or so, I always forget how git worked exactly. Furthermore I am not interested at all about how git works. It’s a tool it should not get in the way. If I perhaps used git every day I would have learned it well by now and I wouldn’t keep forgetting.

        Yes, having to be tethered to check log seems like a drawback. But vast majority of “information lookup” I need while programming comes through the net. The commit log is just one small part. Plus even when working on a somewhat busy project I did not check commits any more often than when I was actually checking stuff into the central repo in which case you need to be connected anyway. I will far more often need to look up documentation or source of a function that simply isn’t installed on my computer than I would need to look up what happened 3 months ago with the source I am working on.

        I am not necessarily holding up CVS as prime example of user-friendliness, but it is simple. I don’t remember having necessarily a long period of learning with CVS. It has a very simple model and it doesn’t try to do much magic. My main point on cvs is “don’t fix what ain’t broke.”

        If you just want to check history while offline, you could just mirror a CVS repository on your own machine. Just like with any information source you may need.

        Comment by jlebl — August 31, 2010 @ 10:09 pm

      • I agree with you about CVS being simple under the hood, and I like CVS for that. It makes CVS better than SVN to me. But Git also has logical simplicity under the hood, which is much less hackish than CVS.

        The funny thing is that when I first started with CVS, back when it was the only thing around, I only used it spasmodically, and I could never remember how to use it. I thought diff and patch were the way to go, and CVS was some convoluted, roundabout way to do the same thing.

        It was only after I started using CVS every day that I realized how much better it was than using diff and patch and separate directories for multiple branches and versioning. And you can do some really nifty things with CVS once you understand the low level. I was using CVS everywhere.

        Git was similar to me… it wasn’t until I read “Git from the Bottom Up” that it started making sense, and I saw the Unix philosophy underneath. i.e. Unix says “everything is a file.” Git says “everything is a SHA1-summed blob.”

        I can understand the bother of having to learn how something works underneath before using it, but Unix is the same way. Unix (especially command line) is stupid and hard for people until they grok the concepts. Maybe it’s too much work to learn pipes, or shell scripting, and not everyone has to learn it. But those that do have a powerful tool under their belts.

        I actually find that understanding git simplifies the whole DVCS thing. Git just puts new names on things I do anyway, and it does all the SHA1 checking for me. On the Barry project, I can track (and I do track) multiple developers and check their work from the command line, without having to change my tree at all. I can push to 4 different git repos to make things easier for users, *and* push to CVS, for those that don’t want to bother with git. Of course, I had to script this, but at least it is possible.

        It’s gotten to the point now where I use git everywhere. Even projects that use CVS or SVN find themselves in a git repo on my local disk, and nobody has to know.

        I did an Intro to Git presentation at my local LUG recently. If you’re interested in the slides and examples, you can grab them with git itself. I don’t mean this as a shameless plug, but I find that the seeming complexity of git drives people away, which is unfortunate, since there are simple concepts waiting underneath, which make the whole thing easier to understand.

        I’ll put the URLs in a separate reply, so you can delete them easier if you don’t want them on your blog. I hesitate using other people’s blogs in a self-promoting way.

        Comment by Chris — August 31, 2010 @ 11:18 pm

      • You can grab the slides with:

        git clone

        And the video (kinda dark, nothing special) from here:

        Comment by Chris — August 31, 2010 @ 11:19 pm

      • Feel free to post the URLs here. I have no “agenda” against git. It just annoys me sometimes.

        Comment by jlebl — September 1, 2010 @ 12:26 am

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

Create a free website or blog at

%d bloggers like this: