Thursday, May 26, 2016

The old 'TFS Repository can not be root and must start with "$/"' error

When using git-tfs to clone a repository using the bash shell, this error is common:
$ git tfs clone https://tfsserver/tfs/DefaultProjectCollection/ "$/path/to/tfs/project"
TFS repository can not be root and must start with "$/".
You may be able to resolve this problem.
The solution? Prepend MSYS_NO_PATHCONV=1 to the command, e.g.:
$ MSYS_NO_PATHCONV=1 git tfs clone https://tfsserver/tfs/DefaultProjectCollection/ "$/path/to/tfs/project"
Initialized empty Git repository in C:/Projects/path/to/tfs/project/.git/
Fetching from TFS remote 'default'...
C6782 = 81584efc08348f7dc4c81297e4e82115789a1e3d
C6784 = 6a6a8bd55111286b24c7acd4825e4ef79030d693
C6863 = 60e8369f34b16a6123d7ed22bf60e59db46ee2e9

Friday, May 20, 2016

GitTfs commands I use every day

Kind of a placeholder for me, but these are a few commands I use every day when keeping my Git repo up to date with TFS.

Since I have many TFS projects as subprojects, I execute this script:

Then, for each subproject, I execute a command similar to the following:

Friday, April 15, 2016

TestDisk - Partition Recovery and File Undelete

I wish I'd known about this a few months ago. I accidentally make a disk unbootable, but eventually, after many hours of struggle, I got it working again. This might have save me those many hours.

TestDisk - Partition Recovery and File Undelete

I found this reading the original Server Fault post on the huge data loss allegedly suffered by someone at a British web hosting company.

Linux command line mistake nukes web boss' biz • The Register

centos7 - Recovering from a rm -rf / - Server Fault

Thursday, March 03, 2016

Cleaning Visual Studio solutions when using Git

Visual Studio has a "Clean Solution" command, of course, but it's conservative in what it cleans and sometimes leaves detritus around that most of the time you want eliminated. It seems to only clean files -- DLL's and PDB's, mostly, but also content configured to be copied to the output folder -- that are created by the current source code and copied references and other files. It also does not eliminate files created at runtime -- for instance error logs -- that your program may have created. One situation in which files are not deleted by the "Clean Solution" or the "Clean Project" command is when you remove an assembly or project reference from a project before you clean it. The removed reference remains in your project's output directory.

Let Git come to the rescue! Assuming that you have a sensible .gitignore file, the following command will delete all bin and obj folders from your project and all subprojects:

Thursday, January 14, 2016

Deleting git index file, a.k.a. more authoritative methods of dealing with Git line ending problems

The classic problem in Windows with line endings in files repeatedly rears its ugly head. I've tried a number of different ways over the years of dealing with them, but I discovered today that the gitattributes documentation actually gives a recipe for dealing with it, which I'll reproduce here:
$ echo "* text=auto" >>.gitattributes
$ rm .git/index     # Remove the index to force Git to
$ git reset         # re-scan the working directory
$ git status        # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

Meanwhile, the people over at Github have a slightly different approach. (I'm wondering if rm .git/index followed by git reset is the same as git rm --cached -r.) [EDIT: I realize upon studying this that this version will touch all files in the source tree, whereas the version above does not.]
$ echo "* text=auto" >>.gitattributes
$ git rm --cached -r .
$ git reset --hard
$ git add .
$ git commit -m "Normalize all the line endings"
Source: Refreshing a repository after changing line endings (Github)

The potential problem of the Github approach is that it would add files you might not want in your repository if your repository has any extra stuff in it, i.e. if doing a git status before their procedure shows any files not in the repository.

What's very interesting about the Github approach is that it's very similar to my method for removing all files from a repository that you'd actually like to ignore, except that my steps are missing the git reset --hard command:
$ git rm --cached -r .
$ git add .gitignore
$ git add .
$ git commit -m "Remove ignored files."

git reset vs git reset --hard

One thing I'm not sure of is the difference between git reset and git reset --hard in the Github approach. I'll have to think about that another time. :)

Saturday, January 09, 2016

Five advanced Git merge techniques

Some very interesting stuff here.

I knew about (but forgot) #1 -- including "base" in the merge file output -- but some of the other things are pretty interesting as well.

#4 -- git merge-file, which redoes the merge -- looks particularly interesting and powerful and helps out in the classic newlines style situations I often find myself in.

This blog, subtitled "Existential Pontification and Generalized Abstract Digressions," and which I only recently discovered, seems primarily concerned with Haskell but has a huge helping of computer science articles as well. The name of the blog -- "Inside 736-131" -- sounds like the name of a computer science course at MIT. [Edit: now I see that it's apparently Stanford-specific.]