Git commands

git config --list # provides you the configuration for the Git.
git init # tells git to track current folder and all its sub-folder.
git status # gives you the status of the repository that you are in.
git add # adds the file to the staging area
git commit # commits the file to the repo
git log # gives you the details of everything happened in that repo
git log --oneline # gives you oneline version of the same.
git commit -m "comment" # allows you to commit without going in to the file.
git diff # gives you the difference between last commit.
git diff --staged # gives you the staged file and your last commit
git diff HEAD~1 # Gives you the difference between current state and previous state of the committed file, similarly HEAD~2 will provide you the difference between CurrentState and 2 states before.
glit log --oneline gives you the hashcode of all the diffs and you can use that to do the diff with that particular commit.
git checkout HEAD~1 # Checks out a file with the earlier version than the current version.
git reset --hard # resets Git to the last known status.
git reset HEAD # resets the changes back from staging area for that particular file.
When you create a new folder/directory in Git repository, then Git doesn't recognize it and you have to add a readme file in each of the folder for Git to recognize it.
git stash # is similar to creating a shevleset in Visual Studio
git branch # Creates a branch and copies all the files from the master branch
git checkout # Points Git to new branch location.
git checkout master # switches back to the master branch
git checkout . # will undo your local changes.

UI is NOT CI

I have been waiting for a long time to write this blog, but has been lying lazy and thanks to David Platt's article in last month's MSDN, which prompted me to excite enough to get rid of my writer's block.

Literal meaning of UI is user interface and I see it getting intermixed with Cool Interface, which I would name it as CI. I see that this culture started with the onset of WPF and Silverlight. People are using  varying background color in the places where they don't even need it. If you follow the URL http://msdn.microsoft.com/en-us/magazine/gg650665.aspx, where David clearly says how difficult it is to read a varying background color for the eyes.

Microsoft decided to move Visual Studio 2010 to WPF and when I was watching one of the channel 9 videos, Rico Mariani's statement was that it still has the same look and feel as it had in his mom's time. I moved to Visual Studio 2010, because I wanted to use the feature of Mixed Managed/Unmanaged code debugging in 64biit, but it is very unstable, once I started using it. It would have been really helpful, if the team would have spent more time making this feature stable rather than making VS2010 look cool.

There are many websites, which gives you the search result in a cool way based on silverlight, but Google is still winning the war, because it gives you the search results without much flashy UI and not distract you.

I would say that you should focus on UI more than CI. You might win some projects, because you have a cool interface with background color varying transparency, as some corporate executive will like it. But when it comes to real user, it will be a fiasco, if you have focused on it being just cool.

This assembly is built by a runtime newer than the currently loaded runtime

I am planning to move to VS2010 and we develop the library and some other group is responsible for the binary. Now, if we want to move to .NET framework 4.0,but the group responsible for binary saw some compatibility issues and they can't move to 4.0.
I thought well, using the side by side feature of 4.0, I could still move, but when I tried that I got the famous exception "This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."

I followed some of the forums and only thing they had to say that it is not supported. But there is a way you could do that.

For Example, if binary A.exe is built with Target Framework 3.5 and it loads DLL b.dll, which is built with Target Framework 4.0. Now if you try it you will get the following exception "This assembly is built by a runtime newer than the currently loaded runtime". But if you have the access to A.exe.config file, which is application configuration file of A.exe, then you can add following parameters in A.exe.config and it will work even if A.exe is built with Target Framework 3.5.

<startup>
   <supportedRuntime version="v4.0"/>
   <requiredRuntime version="v4.0"/>
 startup>

Let me know, if you need the source code as an example for the same.

Windows Debug Crash only on X64

This is the problem that I have seen, which happens, when you mix managed (.NET) and unamanaged code C++ and try to run this in Debug mode in Windows Server 2008. I get this popup shown above and the release version just runs fine without any issues. This popup comes even before Visual Studio tries to run the process in the debugger. You cannot do maanged mode debugging anyway in X64, but you can still debug just managed code, even if it references unamanged. Well, then I tried to run the process in WinDbg, it crashed as well and the Stack Trace complained about dynamic intializer for a particular type global string declared static in native C++, which was referenced by Managed C++ code. Then, I started a web search and found this interesting article by Danny Kalev (Thanks Danny!) http://www.informit.com/blogs/blog.aspx?uk=30-C-Tips-in-30-Days-Tip-25-overcoming-static-initialization-dependencies When I implemented the static variables as mentioned in the blog the problem went away. Then , a very smart colleague suggested to try #define for string and that also worked. Interesting , this problem complained only about the string. There are global static int variables that this binary has, but it never complained about it. I don't know why? It also complianed about const std::string defined globally.