I copied my Mono mcs Git working copy from Linux to Windows for use with MSysGit only to find out that even after git reset –hard almost all files were being reported as modified by git status. It turns out it has to do with the file permissions (executable bit I think) and the inability of msysgit to apply them on Windows.

$ git diff class/Accessibility/makefile.build
diff --git a/class/Accessibility/makefile.build b/class/Accessibility/makefile
old mode 100755
new mode 100644

The fix is to make git ignore some file mode stuff via:

git config core.fileMode false

Another useful setting on Windows is:

git config core.autocrlf true

I had my first experience with git bisect the other day and it’s awesome. What happened is that I introduced a regression which was uncovered by a failing test. Yes,  yes I know I should have ran the full test suite, but I did the mistake to only run the specific set of unit test for that particular component. Now, the tricky part is that the particular test had no direct connection with the last set of commits so I had absolutely no clue which commit had caused it. Thanks to our QA team and build bot I was supplied with a range of commits which caused the regression. This is when git bisect came into play.

Supplied a range of commits git bisect automatically

1. Given a supplied range of commits starts chopping sets of them and applying in a binary search fashion until you mark the current commit as good. Say if you have 50 commits to bisect it will apply the first 25 if you mark the 25th commit as good then the regression is in those 25 commits so it will apply the first 12 of those and then if you mark them as bad it will apply the next 13 and it will then keep subsetting until you hit the bad commit. Nice and quick.

2. Create a temporary bisect branch where it operates (which when done is automatically removed as well)

The workflow is as follows:

git bisect start

# Mark current commit as bad
git bisect bad

# Set the first good commit - the start of the bisect commit set
git bisect good some-commit-here

.. compile and run tests ...

# Mark the current commit as either bad or good
# Git will automatically apply the next subset of commits if bad
git bisect good / bad

# Done bisecting - we found the bad commit
git bisect reset

There are lots of other cool things that you can do like visualize the bisect set, skip range of commits in side the set or even log your actions to a file so that if you make a mistake somewhere you can just reply the actions from the log file. Ah and last but not least you can also use git reset to manually move up the bisect commits set. For more info check out the manual.

This might be old news for some, but there is a merge driver for Git that can automatically perform smart merges of ChangeLogs. I’ve used it for months now and it has always worked flawlessly.

1) Install git-merge-changelog which is part of gnulib . For openSUSE you can use my repository at http://download.opensuse.org/repositories/home:/i-nZ/

2) Make Git aware of it by adding the following to your ~/.gitconfig

[merge "merge-changelog"]
name = GNU-style ChangeLog merge driver
driver = /usr/bin/git-merge-changelog %O %A %B

3) For each repository where you want to use this driver make Git aware of it by adding to $GIT_REPO/.git/info/attributes the following (create the file if it doesn’t exist):

ChangeLog    merge=merge-changelog

That’s it! Enjoy.

Use Case

You are using Git and git-svn on a big project which has lots of branches and tags but you only need to work with a small selection of those and you don’t want to import all of the rest.

Import an individual SVN branch

1) Define the new branch in .git/config :

[svn-remote "release-branch"]
        url = svn+ssh://xxxx@mono-cvs.ximian.com/source/branches/mono-2-2/mcs
        fetch = :refs/remotes/git-svn-release-branch

2) Import the SVN branch. SVN_BRANCHED_REVISION is the the revision when the branch happened in SVN.

[~]$ git svn fetch release-branch -r SVN_BRANCHED_REVISION

3) Hook up a local Git branch to the remote branch:

[~]$ git branch --track release git-svn-release-branch

5) Checkout and update

[~]$ git checkout release
[~]$ git svn rebase

Done!

Delete the branch checkout

The following command sequence will delete (locally only) the SVN branch and its history:

[~]$ git branch -D release
[~]$ git branch -D -r git-svn-release-branch
[~]$ rm -rf .git/svn/git-svn-release-branch
[~]$ git gc

Now what?

Well, for starters given that you are ready to commit something to trunk and you also want to “backport” to the release branch you just have to do:

[~]$ git svn dcommit
[~]$ git checkout release && git svn rebase
[~]$ git cherry-pick master && git svn dcommit
[~]$ git checkout master