the corner office : tech blog

• Benchmark start-up and system performance for .Net, Mono, Java, C++ and their respective UI

Git/Windows/Eclipse line ending fun. I've already set up Eclipse to create new files as Unix but git has other ideas.

• GitHub help: dealing with line endings

• To fix an already duffed file in Eclipse, go to File | Convert line delimiters to...

I created a local clone of my main (in git-speak 'origin') repo for one of my projects, and after committing locally and then doing a git push I got this error:

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.

After reading this it started to make sense. My main/origin repo looked like a first-class, in-use repo, and git thinks that since it might be an active repo, pushing to it would be a bad idea.

The solution was in the post above. Step 1 is to change to the directory containing the origin repo and execute

git config --bool core.bare true

With that done, git knows that the repo is bare, and you can push to it.

Step 2 would be to delete of any checked out code in the origin directory so that all that directory contains is the .git directory.

So you've just been hired by an IT department... and it's your first job. Here's what they didn't teach you in college.

(via)

In the good old days before maven all my projects would be standalone in CVS modules. I wanted to combine a few CVS modules which I'd recently imported into a single maven project, with a single git repo. This page (which I'd linked to before) has the details. I chose the git filter-branch option since it looked relatively painless.

Using the monster git filter-branch command mentioned on that page, I got the error:

Cannot rewrite branch(es) with a dirty working directory.

A quick google found this page which mentions the issue and suggested making sure that git status reported "nothing to commit". My problem was that git status was saying that, and yet I still got the error. What I actually needed to do was run

git add .

After that git status still reported "nothing to commit" (unsurprisingly), but filter-branch now ran fine.

I've been using git for a while now, and I'm sold. New pet projects are going into git but I still had a years-old CVS repo, containing dozens upon dozens upon dozens of projects. After a few abortive attempts I managed to get the lot converted. This is how I did it.

I settled on cvs2git which is part of the cvs2svn toolset. A simple apt-get install cvs2svn on Ubuntu. I worked through the instructions on this page, which I'd linked to before.

You really need to run the conversion per module, because if you point cvs2git at your top-level CVSROOT, it'll mix up all tags and commit logs. I created the script below to automate the whole thing. My bash scripting skills are anything but l33t, but it did the job.

The steps:

1. Create and change into a working directory. The script will create a convert subdirectory, into which all the converted modules will go.

2. Create a copy of cvs2git-example.options (which a simple locate should find - probably somwhere in /usr/share/doc/cvs2svn/examples) in the working directory. Rename to cvs2git.options (or edit the script appropriately).

3. In cvs2git.options, find the line containing text

   r'test-data/main-cvsrepos'
   

   and replace with

   os.getenv('CONVERT_MODULE'),
   

   That line tells cvs2git which repo to convert. Using an environment variable allows the bash script to repeatedly export the module to convert.

4. Dump this script into the working directory:

   #!/bin/bash 
   # script to convert CVS repo to lots of git modules
   
   CFG_FILE=/path/to/working/dir/cvs2git.options
   REPO=/path/to/my/cvsroot
   
   function generate_blob {
   	export CONVERT_MODULE=$REPO/$1
   	cvs2git --options=$CFG_FILE	
   }
   
   function git_from_blob {
   	if [ -d $1 ] 
   	then
   		rm -rf $1
   	fi
   	mkdir convert/$1
   	cd convert/$1
   	git init
   	cat ../../cvs2svn-tmp/git-blob.dat ../../cvs2svn-tmp/git-dump.dat | git fast-import
   	git checkout master
   	cd ../../
   	rm -rf cvs2svn-tmp
   }
   
   function convert {
   	if [ -d cvs2svn-tmp ] 
   	then
   		rm -rf cvs2svn-tmp
   	fi
   	if [ ! -d convert ]
   	then
   		mkdir convert
   	fi
   	generate_blob $1
   	git_from_blob $1
   }
   
   for FILE in `ls $REPO`; 
   do
   	convert $FILE
   done
   

5. Run the script. The 'Already on master' warnings come from the git checkout master command, which is needed to actually check out code from the newly created git repos. It doesn't seem to have any adverse effects, and if the repo isn't going to be used in-place the git checkout could probably be removed.

All seems fine after the conversion, which is to say all tags and commit logs seem to be in place.

• Stack Overflow: how can I move a single directory from a git repository to a new repository whilst maintaining the history?
• move git repository out of a folder?
• rename a gitosis repository
• Converting CVS to git
• Stack Overflow: combining multiple git repositories

Not as simple as on Linux.

• msysGit
• tortoisegit
• github: An Illustrated Guide To Git On Windows
• Stack Overflow: Git under windows: Msys or cygwin?

I'm playing with Visual Studio again.

Compiler warning C4251. Oh, the trouble a std::vector can cause in a dll.

• unknownroad.com: Microsoft Visual Studio .NET 2003 Warning C4251 - applies to 2008 as well, a good write-up
• MS documentation for the warning
• a not-particularly-helpful tech note

gitvsmercurial.com

All fine and well, but which to choose? I've used CVS for my personal projects for years, and been planning to move to svn for ages. Is it worth going with svn? I figure if I'm going to make the jump, I may as well make it a big jump. The choice between Git and Mercurial seems to boil down to 'fast, finicky and poorly documented' versus 'slow but predictable and well-documented'. I can see benefit to both, which makes me think that a worthwhile approach would be to see what works best with Eclipse (since that's what I do most of my coding in.)

StackOverflow rocks, as always.