Friday, January 6, 2012

(E)Git Pain, Git Joy

I've been using git in anger for about a week now, after we migrated our repos at work to github. I thought that after half a day of struggle, accidental bad merges, and confusion I finally managed to get the hang of EGit. Lots of right-clicks (hey, it's Eclipse so whatever), remember to commit, then push, great.

Today, a coworker and I do a little pairing, write the skeleton of some new features. I commit and push my changes and leave to go to a meeting that ends up going for 2 hours, only to return to a request that I add a new file that had gotten missed in the commit. Why, why, why do I need to ADD this file? I understand that commandline git (and svn) require "add" before commit, but using Subversive for the last few years I've gotten out of the habit because, seriously, if I highlight it to be checked in just add it for me.

I also seem to keep hitting problems with merging when I've made changes to files that have subsequently been changed. No matter how unrelated and auto-mergeable the changes are, EGit doesn't seem to let me pull them.

These may (probably) be user error but it is so tiresome to be yet again at a place where the tools have not caught up with the cool new thing and don't bother to streamline the common case.

On the other hand, we had a production issue tonight. Right now, the production release process for this particular code is "check out trunk, restart" (yeah, yeah, I'm working on it, it's only been a month ok?). At some point I realize that this change is bad enough that I just need to go back in time to where the code was more stable, and deploy from there. Despite a lack of tags or branches involved in the current process, this was quite easy to do.
git branch rollback_0106
git checkout rollback_0106
git reset --hard <checkin>

Then push the branch, and release from that branch. It's incredibly fast, and very easy. I also was easily able to create a branch with some failing tests for my coworker to look at, without much hassle or annoyance.

So the jury is still out for me, but really I suspect the problem is just that the tooling has not caught up to the technology. Sadly, it seems you only get a little time in the sweet spot of good tooling and good technology before being forced to move to the next hot thing. I guess this is why most people just stick with the command line...


  1. I've completely given up on IDE integration for version control. (Blame Google.) Honestly, it feels kinda good. I almost never bothered with Eclipse-SVN integration at GS either.

    Looooove Git, though.

  2. egit is a pure Java, complete re-write of git. It's not reasonable to expect it to be good yet. Embrace the cli for now.

    Every version control makes you manually add files from the cli. IDEs tend to guess that you want to add everything that's not build output. Git adds the concept of the index which is confusing at first, but pretty powerful when you need it.

  3. Yeah, like I said, I know that version control makes you add files, but I really, really want something smarter than that.

  4. I have the git add problem too. You could always do the lazy thing and alias git-commit to git add dirname $@ && git commit %@, or whatever. I haven't bothered, but I've thought about it.

  5. git add -u will add all changes to previously checked in files.

    git add -A will add everything. You have to be careful to use .gitignore though or it will add your built binaries.

  6. The first two sentences are the same as my experience, except that I'm still using the command line and haven't found a wrapper that makes git any nicer. Some people at my company are using the PyCharm IDE, I and some others are using emacs. The IDE folks are having mixed success, able to do some things, falling back to cli pretty often.

    Another failure about `git add`: it snapshots the file right then. If you edit the file some more, you need to add it again.

  7. That's not a failure, that's a feature.

  8. The solution to that is to do what I do... git commit -a, every single time.


Note: Only a member of this blog may post a comment.