git-tf second encounter

I started using git-tf just before they released version 2 that introduced a few changes, so I was a bit confused about the ‘unexpected’ results.
Let’s start with the things that didn’t change.

One changeset vs all changesets

By default, when you do a git tf checkin all the commits (since the last time you pulled in changes from tfs) get squashed into one. I can understand why this possibility is in there, but my default setting would be different. Luckily, I can change this and there are 2 ways.

• use git tf checkin --deep
• git config git-tf.depth 2147483647 - no need to use the parameter after that, and if you do want to sqash git commits into one tfs changese, you can eiter use --shallow or git rebase –i

Choosing  wether to use the --deep or --shallow option does influence a couple of things, so make sure you know what you want. Squashing things into one commit prevents from having to cancel multiple queued builds (if you push 10 commits, and the build config is set to trigger on each one, it’ll queue up a build for each commit) but at the same time prevent you from having a ‘clean rollback’ scenario or cherry picking if required later on – so for me, cancelling builds it is – I push to tfs once or twice per day so that’s not too much work. Note that the timestamps for tfs checkins will not match the timestamps from git.

Workspace locked

If you do a git tf clone into a directory that is mapped to a tfs workspace (or one of its ancestors is) then you won’t be able to check in the changes, so as a rule of thumb, use a separate directory

Solution in source control

Visual studio adds source control provider bindings to the solution file – if you want to use git-tf I suggest to remove these, otherwise expect glitches while working in VS.

Git in VS

If you want to have git support in VS then you’ll probably want to install a git source control provider

Line endings.

Git-tf recommends setting autocrlf to false in git settings. I found that setting it to true works better for me.

Changeset comment

Added in version 2 there is a possibility to push git commit metadata into a tfs changeset comment. This produces a rather obscure comment if you view the log, but it does contain e.g the git commit timestamp, so if you’d like that then go ahead and use it, if not, provide a --no-metadata parameter to git tf checkin. At the moment of writing, it is not possible to store this in git config. It would also be great if the message template would be somehow configurable – but I guess we’ll have to wait for the next release

Summary

This list is quite lengthy and you need to add things from the previous post so this does seem like a big hassle just to change one scm into another and for a moment I did give this approach a second thought, but then I looked at the bright sides. I am no longer slowed down by my internet connection and thus checkin speed and I can finally split my checkins as I want, because git does handle this better.

Cheers