I love Git. But msysgit, while not horrible, could be a lot better.

For example, there’s an extension called git-cheetah. When you install msysgit, that’s one of the questions for you to answer, and it’s asked in a nicely slanted way:

• Simple context menu (Registry based)
• Advanced context menu (git-cheetah plugin)

I’ve found people who say “avoid this like the plague”, and others who use it. It actually took a little while to find out that this is shell integration a la TortoiseSVN. Shell integration is wonderful, except when it breaks, and it’s just complex enough that most people can’t troubleshoot it to fix the problem.

And it’s really something that you could ignore. Do you use context menus while developing? If not, then this choice is irrelevant. If you do use context menus, then (1) they need to always work, and (2) you should be able to use either or both.

Another issue with msysgit is the dreadful out-of-the-box performance with ssh connections. This is particularly bad because ssh is a very common way to connect to remote git repositories; it’s quite nearly the default for pushing to remote repositories. So you’d think that, of all the things to make sure worked well, it would be SSH. But if you want good SSH, you need to drag PuTTY in and use pagent and plink.

There’s little every written about msysgit, I don’t know much about how it’s developed or what choices are made. On the other hand, the main Git development is about as visible as you can be.

Another reason I feel awkward about msysgit is that there’s a lot of whinging on the part of the main developer; at least as of several years ago, he clashed with the Git mainline developers, and was pretty rude and insulting to boot. I mean, irrespective of who’s right and wrong, you don’t cut off your oxygen. If you’re dependent on someone, you want them to look favorably on you.

I really wish that the mainline Git developers would take a more cross-platform approach and mindset, but they are Linux developers first and foremost. It’s not surprising, given that Git’s parent was Linus Torvalds; I definitely wouldn’t expect him to care about Windows or Mac. However, Git is becoming the best revision control system on the planet, and a lot of people use Windows and Mac machines, and they aren’t going to switch just because of Git.

We need a first-class Windows client for Git, but it has to be part of the mainline development, it can’t be some parallel development process. Those always start out well, and then die after a year or so.

git rebase is awesome, because it lets you fix your history after the fact. It’s not about rewriting history, it’s about improving it so that it makes more sense, or so that it’s composable.

But git rebase also breaks workflows. If you rebase work that others have built on, you create problems for them, because Git will get confused about how to merge. That’s bad, because a lot of Git’s power is based on the idea of constant branching and merging.

One of my pet projects is to figure out how to allow both constant branch/remerge and rebase to co-exist happily. I have no clear idea how to do this, just some vague ones. At some point, I’ll work on this. But if someone else were to do it before me, I’d be just as happy.

Hint, hint.

I like Github. But I also like control. I wonder if Gitlab will be a useful choice?

http://gitlab.org/

There’s an article here that talks about setting up a Gitlab instance:

https://www.digitalocean.com/community/articles/how-to-set-up-gitlab-as-your-very-own-private-github-clone

This one is pretty cool.

Git Cheatsheet

It shows all commands relative to what portion of the conceptual workspace they modify – e.g. stash, workspace, index, local repository or remote repository.

That said, it stops at the one-line summary for a command. In looking at this, it would be cool if you could see commands in action in terms of how they modify data, but still at the logical level, not as yet another of the interactive git tutorials.

This is a cool feature. You can mark files as “yes, I know this is tracked by Git, but I don’t want my changes committed.”

For example, there’s a config file that’s checked in. You need to make local edits to test with. However, you often accidentally commit those changes (you forget). But you could tell Git to ignore changes in this file. Let’s say we have a file config.xml that we want to edit locally and leave edited.

git update-index --assume-unchanged config.xml

After this, we can commit all we want, and Git will ignore config.xml. If you need to commit a change to it, you can undo this with

git update-index --no-assume-unchanged config.xml

If you’ve forgotten which files you have set the “assume unchanged” bit on, you can do git ls-files -v to see.

This is an edge case, but useful for some work flows.

New standalone “run Git as a server” Java stack.

http://gitblit.com/

There’s a version prepackage with Jetty for a download-and-go approach, or you can get a WAR and run it in your servlet container of choice.

It uses Jgit as the actual Git daemon. It does NOT support ssh yet, just http/https and git protocol.

Source can be found on Github: https://github.com/gitblit/gitblit

This is pretty cool. I think I want this at work.

https://choir.io/player/f9c750f2bedb0c0f