Tim Barcz : Git

Open Source Whining

Tim Barcz — Wed, 28 Jul 2010 14:04:28 GMT

Was working on a blog post talking about a problem I’ve found in Git (1.7.0.2) and I thought I would check to see if it’s been fixed in the most recent version. After downloading and installing I reviewed the release notes where I’m quite shocked to read the following:

“…All hopes to the contrary, Git for Windows is backed by only a handful of developers, in spite of being downloaded almost one hundred thousand times. You can expect developers to be enthusiastic to fix others' issues in such a situation only for so long. In short: Do not expect other people to fix your issues for you.”

Basically, what I get from this is that the msysgit committers are a bunch of whiners. What they fail to see is that the people who would benefit from their VCS may not have the same skillset to work on the code. This is something we’ve realized long ago with Rhino Mocks.

Should more people help? Possibly. As someone active in open source technology I don’t know that I can be of much assistance to the Git team – I am someone who benefits greatly from their software (I am quite thankful for it) but don’t have the requisite knowledge in C/C++ to assist in any meaningful fashion.

Just a bit disappointed to see this type of whining in their release notes – certainly there are far better ways to say what they’re trying to say. Doesn’t represent msysgit or the broader open source community well.

I Just Cloned, Why Did Git Change My Files?

Tim Barcz — Mon, 30 Nov 2009 04:35:00 GMT

Being new to Git I got thrown off a few weeks ago when cloning a remote repository and immediately seeing changes after the clone completed. Scratching my head a bit, I reached out on Twitter and James Gregory came to the rescue.

How is it that right after a git clone <url>, git status shows modified files? (http://twitter.com/TimBarcz/status/5920294511)

What James showed me was that there is a setting core.autocrlf on your system which needs to match the remote repository. If it does not match, when you clone the directory files will be changed.

After experiencing this myself and coming across it again the other day, I thought I’d put a quick video together showing the problem and the fix, since I suspect others will have it at some point as well.

Git - Core.AutoCrlf Setting from Tim Barcz on Vimeo.

To recap: when cloning a new repository, always perform a “git status” command right after the clone. If you see modified files, a core.autocrlf mismatch is likely the culprit. Change your setting, clone again, and you should be good to go.

Git…Command-line or GUI?

Tim Barcz — Wed, 07 Oct 2009 19:15:02 GMT

A short quick post to get some feedback from you, the reader.

I’m working to learn and transition to Git (using Jason Meridth’s great series on Git). Up to this point I’ve been using the command-line only, working to learn Git on the command-line before I rely on a tool or GUI abstraction. Recently I’ve been going through some refactoring on a project where I’m using Git. Right now I’m slow, really slow. Renaming files/classes for example is cumbersome to say the least.

I got to wondering if knowing the command-line is even useful anymore or it just a geek badge of honor that a few developers like to point to proudly when talking about skill sets? Some part of me feels like using a tool like GitGUI or TortoiseGit is “cheating”. Ironically I admire Git because it seems to let me work the way I want to work; branch often, local commits, easier merging and yet right now the command-line use of Git is my primary roadblock. It is at this point that I start thinking I should give up on the command-line since an SCM tool shouldn’t be intrusive and move to a GUI tool and give up my chances at fifth degree black belt geek.

So what do you think?

Use command-line go slow now but know the tool very well.
Use GUI and go faster, however always be reliant on the GUI abstraction

Is using a GUI “cheating”?