Over the past several weeks I have been committing myself to trying to learn more about Git and actively getting myself in the habit of using it more. I have already managed to read most of the book Pro Git to get a broader understanding and feel for how to apply its many useful commands. In a previous post I also managed to highlight some useful introductory git videos and the graph theory big picture required to understand its underpinnings. Since then I have explored using the software gitk to understand git and found it helpful to take this approach to gain a better visual understanding of what happens with git. Also, by discovering some of the external links of the Git page I have also started reading Git in the Trenches and it is providing a useful different perspective on things.
At the moment I am slowly working my way towards digesting some of the more difficult and unintuitive git commands like git reset. This post by Mark Dominus made me realize that I should be rather careful when using git reset on a git repository. In it he states:
“The Git subcommand git-reset is very frequently used, and is one of the very few commonly-used Git commands that can permanently destroy real work. Once work is in the repository, it is almost completely safe from any catastrophe. But git-reset also affects the working tree, and it is quite possible to utterly destroy a day’s work by doing git-reset --hard at the wrong time.”
Therefore with this warning and real possibility that work could be DESTROYED if git reset is used at the wrong time I knew I had to try and understand git reset more fully. The first place I looked was the git reference page and there I learned that there are basically three versions of git reset:
- git reset HEAD unstage files from index and reset pointer to HEAD
- git reset –soft moves HEAD to specified commit reference, index and staging are untouched
- git reset –hard unstage files AND undo any changes in the working directory since last commit
Obviously each command above is a different form of pointer operation on the git repository’s commits, index and working directory. However, I always manage to find pointers a bit mystifying and perplexing. I always need a picture to understand them. As much as the git reference documentation described git reset in simple and concrete terms I wanted a deeper more visual explanation. The Visual Git Reference was a handy guide to help clarify and visualize the pointer operations occurring when one does a git reset. Not satisfied with this understanding, I wanted a plain and simple explanation of git reset and eventually discovered on Stack Overflow this question Can you explain what “git reset” does in plain english? that was helpful. As always Stack Overflow contains a wealth of information and knowledge. Reading the Stack Overflow responses I found this blog post entitled Reset Demystified that explained git reset through tree roles that gave me a different perspective on the command. Armed with the above knowledge from these resources I should be able to conquer and understand git reset. I have no doubt that eventually git reset will become less foreign and complex to me as I find occasion to use it. I know I will definitely need to try some tutorials and practice using these commands to be less shy of using them in real situations.
Removing Escape Sequence Characters in Git
In my usage of Git on FreeBSD I noticed an oddity that wasn’t occurring on my Ubuntu box. Whenever I would do a git diff or git log the console would print the escape characters (as shown below) rather than colourize the output for each command.
Needless to say this was rather annoying and I went looking for a fix for this. I discovered the following blog post on Avoiding escape characters in Git that said how to correct the issue. In hindsight I learned Git was using more as my pager and it wasn’t interpreting the escape characters. The fix I discovered was simply to switch to a different pager less for git to use with the following command:
git config --global core.pager "less -r"
And my little annoyance disappeared!