GIT stops after unpacking objects or resolving deltas

Clone, pull and push all seem to finish fine, but they always stop at "Resolving deltas" or "Unpacking objects". The root of this issue is the fact that MSGIT uses curl, which does not know how to talk to NTLM authenticated proxy. There are two solutions which worked for me, first one not being stable.

Solution 1: unstable, easiest

This *usually* works:

git clone -v https://myrepo.git
Cloning into 'myrepo-1'...
Password for 'https://user@myrepo.com':
POST git-upload-pack (174 bytes)
remote: Counting objects: 2287, done.
remote: Compressing objects: 100% (1276/1276), done.
remote: Total 2287 (delta 1340), reused 1692 (delta 883)
Receiving objects: 100% (2287/2287), 53.37 MiB | 632 KiB/s, done.
Resolving deltas: 100% (1340/1340), done.

Or another when, when pulling from a repo:

remote: Counting objects: 53, done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 28 (delta 23), reused 2 (delta 0)
Unpacking objects: 100% (28/28), done.

The problem is that nothing is updated on the disk. I have tried using -v in order to obtain more information about what is going on, but I never get more than shown above. I am using Git over HTTPS with the HTTPS proxy well configured - so this should not be an issue.

After un-finished clone, I have noticed, that the objects directory inside the .git directory actually changed it's size quite a lot. So it seems, that the objects are well received but never written to the actual branch. That might sound like a user-rights issue. But I am admin on the machine and I have access write rights on the folder. So for now, I don't know the cause of this problem. I have simple solution to overcome this issue. What I do to fix the repository is quite straightforward:

$ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (2187/2187), done.
dangling commit da575f887db63ccf97f37f9cf96316307398db82

Git fsck always founds one dangling commit. It is a utility which checks the integrity of the object database. Here the dangling commit is a commit which is not used by any branch. To fix the issue I can just merge the commit with the current branch.

$git merge da575f887db63ccf97f37f9cf96316307398db82

And everything works just fine...

Solution 2: stable solution

This needs sone more effort. The solution is to use the CNTLM as a proxy between the NTLM proxy and any application which needs to use it. The solution is exelently described on this blog.

Solution 3: not confirmed

I was not able to confirm this one, but at this thread on StackOverflow someone mentioned to use verify-pack function of git. Verify-pack verifies that .pack files, which are packed objects used by git during the transfer. If the files were transfered correctly you should be able to restore the commits contained inside the pack files. This actually did not work on my post, since the pack file was corrupted.

TFS and UnitTests - QTagent32 crash & "data.coverage' because it is being used by another process"

I made a bug in my code which resulted in never-ending recursion which was produced only while UnitTesting.

When there is recursion in unit test than the QTAgent32 crashes down (this is described here).

But if you commit to TFS than and this commits launches the UnitTests than these will never finish (so if you do not check than you might just have builds running for couple days and new builds in the queue behind).

However when you cancel the build and run a new one, this one will fail, saying:

'data.coverage' because it is being used by another process.

So there is some process which has locked the "data.coverage".
To solve this issue log on the TFS and kill the process VSPerfMon.exe which runs under NT AUTHORITY\NETWORK SERVICE (that should be the account which is running your builds & unit tests on TFS).

Change path of included DLL in Visual Studio 2010

Visual Studio 2010 remembers the previous locations of the DLL, and in some cases prefers the "standard" locations of the assemblies.
In one of our projects we have to add System.Windows.Interaction assembly which you can find in the .NET tab of the Add Reference dialog (well only if you had installed Expression studio before).
But we use Team Foundation Server as Source Control and Continous Integration solution and while this assembly was missing on the TFS server, the "after commit" build did not succeed.

So we took out the reference, copied the DLL to the Source Control and added the reference directly to this DLL. But somehow Visual Studio remembers the original location of the DLL and always points the PATH property of the reference to the original position.

The solution is to change the Project file and add manually the PATH to the DLL file

So instead of:

you can change the reference of the interactivity dll to:

   ..\Libraries\System.Windows.Interactivity.dll