Unleashing the Git - part 5 - git stashing

More often than not, there can be situations where you have done some changes and you need to temporarily hide those from the working tree since those changes are not completely ready yet. Stashing comes into play in such situations. May be when you have done some changes in a branch and you want to switch to another branch without committing your changes in the current branch. Stash is the easiest option for that.

Say you have changed some files. Issuing the git status would show what has changed.

$ git stash // Temporarily hide your changes. Now issue git status. You won't see the modifications. Equivalent to $ git stash save
$ git stash save --patch // Opens the text editor to choose what portion to stash
$ git stash apply // Apply the last stashed change and keep the stash in stack. But this is normally not done. Instead following is done
$ git stash pop // Apply the last stashed change and remove it from stack
$ git stash list // Shows available stashes.

Stashes have name in the format of stash@{#} where # is 0 for most recent one and 1 for the second recent and so on.

$ git stash drop <stash name>   // e.g: git stash drop stash@{0} to remove the first stash
$ git stash clear // Remove all the stashed changes
$ git stash branch <stash name>  // Create a branch from an existing stash

In the next part of this series we'll discuss git branching in detail.

Unleashing the Git - part 4 - Git Tagging

Tagging comes very handy in managing a repository. Tags and branches are similar concepts. But tags are read only. There are two types of tags. 1) Lightweight 2) Annotated

$ git tag Basic_Features    // Creates a Basic_Features tag.
$ git tag            // Shows available tags
Basic_Features
$ git show Basic_Features   // Which show the details of the commit on which Basic_Feature tag is added
$ git tag beta1 HEAD^ // Creates a tag from next to last commit

Earlier I showed how to check out code with commit id. We can also use the tags to checkout code of a particular stage using the following command.

$ git checkout Basic_Feature

All of the above are lightweight/unannotated tag. Creating an annotated tag is as simple as creating lightweight tag as below,

$ git tag -a Basic_Messaging_Annotated -m "Annotated tag at Messaging"
$ git show Basic_Messaging_Annotated   // this will provide the details of the tagger as well.

Deleting a tag is same for both tag types.

$ git tag -d Basic_Messaging_Annotated  // Deletes the annotated tag we created.
$ git push origin v1.0 // Push local tag v1.0 to remote origin.
$ git push --tags origin // Push all the local tags to remote origin
$ git fetch --tags origin // fetches all the remote origins tags to local repository. Note: If you have a local tag with same name as a remote tag, it'll be overwritten

Unleashing the Git - part 3 - Working with remote repositories

More often we need to share the files that we modify and make it available for other users. This is typically the case in Software development projects, where several people work on a set of files and all needs to modify and do changes. The solution is to have the repository in a centralised place and each and every one work with there own copies before they commit it to the central place. There are many online git repository providers. Examples are GitHub, BitBucket etc.

Choose, whatever best suites for you and sign up for an account. Most online repositories provide free accounts. I've a created a one in bitbucket and have created a repository named online_workbench.

$ git remote add origin https://shazni@bitbucket.org/shazni/online_workbench.git  // Syntax is git remote add <name> <repository URL>
$ git remote rm <name> // To remove a remote from your local repository
$ git push -u origin master
Password for 'https://shazni@bitbucket.org':
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 88.01 KiB, done.
Total 4 (delta 0), reused 0 (delta 0)
To https://shazni@bitbucket.org/shazni/online_workbench.git
 * [new branch]      master -> master

Branch master set up to track remote branch master from origin.

After you entered your password, you'll have your repository online and its local location is your local $HOME/example directory.

'git push -u origin master' is to make the git aware, that all the pull and push operations to default to the master branch. If in case '-u origin master' is not specified, each and every time you issue a 'pull' or 'push' command, you will have to specify the origin.

Ok.. Now if someone needs to get a local copy and work on this remote repository, what he/she needs to do? Only few steps are involved.

First we need to clone the repository into a directory. Navigate or create a new directory where you need the local clone of the repository and issue the following command.

$ git clone <remote repository location> <Path you want the clone to be>

If you omit the <Path you want the clone to be>, it will be in the current directory.

Depending on how the firewall on your computer or local area network (LAN) is configured, you might get an error trying to clone a remote repository over the network. Git uses SSH by default to transfer changes
over the network, but it also uses the Git protocol (signified by having git:// at the beginning of the URI) on port 9418. Check with your local network administrator to make sure communication on ports 22—the port SSH communicates on—and 9418 are open if you have trouble communicating with a remote repository.

$ git clone --depth 50 <remote repository location>  // Create a shallow clone with the last fifty commits

Then, if we do the modification to the files or added files, next we need to stage it for commits. Issue the following commands.

$ git add *            // Stages and add all your changes, This is similar to git add -A 
// If you specify git add -u will only previously added and updated files will be staged. -p parameter will present you with sections so that you are given option to include a change or not.
$ git commit –m 'My commit comment'     // Commit the changes to the local repository
$ git pull        // checks whether there are any unsinced updates in the remote location and if exist syncs local and the server
$ git push        // Add the changes made by you to the server

Building boost C++ library

Boost is a well written portable C++ source library. It's a very popular and flexible library set to use in you C++ applications. It has a huge set of libraries spanning across many utilities and uses. Good thing about Boost is that, the libraries available in Boost are either already available in C++ standard or likely to end up in it one day. Note however, not all libraries are accepted. Nevertheless, all the libraries are proven and well tested.

Download the latest boost library from http://www.boost.org/

In this short guide I'll walk you through the process to easily build boost for you to generate the header and library files for you to use in your C++ application.

Once you download the boost, extract it into a directory. Navigate into the extracted directory and issue the following commands. Make sure you have a C++ compiler available in your system (e.g: g++ in GNU/Linux). Look here (which is a generic post, however) to see how to install C/C++ compilers.

$ ./bootstrap.sh --prefix=path/to/installation/prefix

$ ./b2 install

Depending on your system tools, you may not have all the libraries built. For example, if you do not have python dev packages installed, boost python library won't build. But this won't stop building other libraries.

You are done!!! You should be able to find two directories inside the directory you specified in the PREFIX; namely includes and libs. These contain header files and .so (or .dll in Windows) shared library files to link in your C++ application.

WSO2 Microservices Framework for Java (MSF4J) 1.0.0 is released

WSO2 is pleased to announce that it has released the very first version 1.0.0 of the WSO2 Microservices Framework for Java (MSF4J). You can get more details from the following location.

[1] http://wso2.com/products/microservices-framework-for-java/

It gives you a lightweight fast runtime together with an annotation based programming model to create your micro services. Browse the following location for a quick start guide.

[2] https://docs.wso2.com/display/MSF4J100/Quick+Start+Guide

Enjoy creating your microservices!!!

Unleashing the Git - part 2 - git log and git stat

This is the 2nd part of the Git posts I'm currently blogging on. You can find the fist part here. This part focuses on the git logging and its various outputs and statistics generation in git. These information are vital for developers. Some of the uses are to see the recent changes, diffs in recent commits, who made what change etc. Let's dive into these commands and see what they have to offer us.

$ git shortlog

Shazni Nazeer (10):
      First commit
      Removing compliled files
      Removing log files
      Verifying folder existence
      create directory called logs
      Data loading from DB
      More logging configurations and message parsing
      adding MessageProcessor.py
      Handling of few user requests
      Bug fixes and Items ID is changed to VARCHAR from INT

Above command arranges all the users who were involved in building the repository data in alphabetical order, showing number of commits they have made along with descriptions. Of course if you have only one user contributing, only that users information is listed. If you specify a -n parameter to the same command it will order the users by number of commits.

With -e parameter we can get the email address of the user, whereas the -s parameter gives a summary of each users stages/commits.

git log command as I stated earlier gives git commit ID and other meta information. If you specify --skip=<number> it will omit last <number> of commits and show only others. Following are handful of git log examples that you may find useful in your day to day development work.

$ git log -p // Shows the commit changes
$ git log -1 -p HEAD   // To see the latest commit
$ git log -p -2 // Limit the output to only last two commits, also shows the diffs
$ git log -5 // Shows only the last 5 commit without diffs.
$ git log HEAD^^..HEAD   // Same as git log -2
$ git log --skip=4   // Skips the last 4 commit details
$ git log --since=2014-02-27 --until=2014-03-10   // Only get commit details between the specified dates
$ git log --since=2.days // Find commit of last 2 days - If 3.months - Since three month before
$ git log --since="1 week" == git log --after="7 days" == git log --since="168 hours"
$ git log --before="1 week" == git log --until="7 days" == git log --before="168 hours"
$ git log --author="some user"
$ git log --grep="user" // Finds all the commits with a descrpition having the word user. -i paramter at the end ensures case insensitive search
$ git log --stat  // Gives details with files changed
$ git log --pretty=oneline
$ git log --pretty=format:"%h - %an, %ar : %s"
$ git log --pretty=format:"%h %s" --graph
$ git log --oneline // first seven characters of the commit id and the commit message shown
$ git log -- some/path/
$ git log -- somefile

It's often the case while developing that you add few files to your repository mistakenly or for testing which you never intent to commit. You can use git clean command to remove those. Let's assume we need to remove all the text file with extension .txt

Following two commands will do it.

$ git clean -f -e*.txt
$ git clean -f

Getting information in git is not limited to git log command. We often need to know more information on individual files changes and other useful information. git diff command have plethora of options to provide you with required information about your repository. Let's check some of the commands that you might find useful.

$ git diff // The diff between the working tree and the staged area
$ git diff --staged // View the difference between staged changes and the repository

View the differences between the working tree and a commit in the repository

$ git diff HEAD
$ git diff <Commit ID>
$ git diff <first commit id> <second commit id>    or $ git diff <first commit id>..<second commit if>  // View the differences between two commits.
$ git diff -- path/ // Limit the diff output to a specific path
$ git diff-tree -p COMMIT // Where COMMIT is your commit number to see what was changed in that commit

Generating stats
 

git diff can also be used to get some statistics output in addition to differences in the source code. Some of the examples are as shown below.

$ git diff --stat HEAD~5  or git diff --stat HEAD~5 HEAD  // Show change stats between last 5 commits
$ git diff --stat <first_commit_id> <second_commit_id> // Stats between two commits 
$ git diff --shortstat HEAD~5 // Shows number of files changed, insertions and deletions.
$ git diff --numstat HEAD~5 // Shaows the stat in more 
$ git diff --stat -p HEAD^  // also shows the oatch in addion to stats
$ git log --stat  // Shows full stats along with logs
$ git log --shortstat // Shows Cumulative stats only along with usual log

There is a command that can used to give information on invidividual user responsible for changes in source file by line number. git blame displays all or a portion of a file with annotations showing when

the change was made, by whom, and, more importantly, in what revision the

change was made.

git blame outputs the following information:

• Short commit ID

• Author’s name

• Date and time of commit

• Line number

$ git blame <some_file> // To show the entire file with line by line info on above
$ git blame -L 20 <some_file>  // Starts blaming of the beginning from line 20
$ git blame -L 100,120 <some_file>  // Limit the blame to lines 100 to 120 
$ git blame -L 5,+20 <some_file>   // Limit the blame starting from line number 5 to 20 lines
$ git blame -L 30,-13 <some_file>  // Get the blame of the file from line number 30 to 13 lines behind
$ git blame -L "<POSIX Reg Ex>",+20 <some_file> // Get the blame of the specified file from the line matching to regex to 20 lines ahead

Git can track content that moves around in a file or is copied from one file to

another. You can use git blame to show content that has moved around by

adding the -M parameter.

$ git blame -M <some_file>     // To see which part has got moved around in the specified file

You can also track changes copied from another file by using the -C

parameter. It checks the changes in the file against other changes in the

repository to see whether it was copied from somewhere else. 

$ git blame -C <some_file>     // To see which part has got copied from another file in the specified file

Unleashing the Git - part 1 - Fundamentals

Git is a distributed version control system. It has become extremely popular and replacing other version control systems in the industry very fast. Hence, knowing some day to day uses of git is very essential for all developers. I thought of writing some series of posts to cover some very useful git usages along with an example for you to grasp it easily. This is the first post of that series.

Before we delve into details on using the git, make sure you have git installed. If not, you can find details of git installation in the following location.

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

Ok. Assuming you have git installed, let's dive into using it. 

Go into a directory where you want to monitor for changes. Let's create an empty directory called 'example' in $HOME. I'll refer the directory as $HOME/example from this point.

Most of the commands and examples are in par with the following two books related to Git. It's really worth the time to read these two books if you are working with git on day to day basis.

Git: Version control for everyone
Pragmatic Guide to Git

$ cd $HOME/example

First, let's find out some initial git commands you might come across when initializing a git repository.

$ git init

Initializes empty Git repository in /home/shazni/example

To configure Git, you can use the following commands:

$ git config --global user.name "your full name"
$ git config --local user.name "your full name"
$ git config --global user.email "your email id"
$ git config --local user.email "your email id"
$ git config -l // lists all the configuration variables
$ git config --global color.ui auto  // Optional
$ git config --global core.editor /path/to/editor  // Optional
$ git config --global merge.tool "gvimdiff"   // Setting the diff tool for git mergetool command

Before we proceed, if you need any help on git, issue the following command.

$ git help

If you need to see the built-in documentation of a particular command, you may issue

$ git help <command name=""></command>     // e.g. git help init  

Now copy a file called abc.doc to the directory. This file is still not being monitored by git. Hence, it is referred to be in unstaged state. To make it into staged state, i.e. to make it available for git to monitor it, we have to issue the following command.

$ git add abc.doc

Issue the following command to see the status of all the files.

$ git status

To add multiple files, we may use the following commands,

$ git add .
$ git add *.docx

Remember these commands would add all the files and all the .docx files to the staged state respectively. This includes all the temporary files of the original files, which is often named after ~ with it's original name to save state of the files for disaster recovery. For example when abc.doc is open there can be another file name ~abc.doc. When we use 'git add' even this file is staged. This is at times troublesome. Git has a workaround for this. We can create a file named .gitignore and specify what files and what types of files we need to ignore from 'git add'. Create a file named .gitignore and type the following.

~*.*

This is a pattern. This says to avoid all temporary files like ~abc.doc

Undoing Uncommitted Changes

git reset abc.doc // To make from staged to unstaged before commiting or more specifically

git reset HEAD -- abc.doc // Here -- says Git that everything follows are file names, not commands

With git reset you are telling Git, “Change the index— the staging area — to the latest version of this file.”. Normally git reset is used when you want to unstage already tracked files

Following is normally used to un-stage new files that you staged but still not in git's control. The file will still be in the local working tree

git rm --cached abc.doc // git rm is usually done to rm files from remote repository. Adding --cached options tells to leave the working tree alone.

git checkout -- abc.doc // Caution : Be careful with this command. This will completely wipe out all your current changes and brings back the old file you committed

Though the files can be staged/unstaged it's still not under version control until we commit the files. Only then Git will look for changes of the current version with the last saved version.

$ git commit -m "Initial commit"
$ git status // There won't be any unstaged or even staged files. All are commited now

Now if you modify a file and issue a 'git status' command. It should show that your file is modified. To include it for next commit, let's add it.

$ git add abc.doc

$ git commit -m "Second commit with changes"

$ git log    // Provides history of the repository. The ouput will be as follows.
commit ca8da1d78daa8453dd478da7610e3c375ae917db
Author: Shazni Nazeer <mshazninazeer gmail.com="">
Date:   Tue Dec 3 12:37:24 2013 +0530

    More changes to Refactor doc

commit 93c1e9296a901bee38806e216d72abd74509a18f
Author: Shazni Nazeer <mshazninazeer gmail.com="">
Date:   Tue Dec 3 12:30:05 2013 +0530

    Initial commit

We need the commit id (the 40 character id in front of the commit word). If we need to checkout the files at the first commit.

$ git checkout 93c1e    // Note only the first 5 character is enough to checkout. 

Now when you checkout, the directory would contain the file before you modified. If you want to checkout a previous commit with latest intact, we need to do branching. Will come back to that shortly. But let's get our latest.

$ git checkout master

Previous HEAD position was 93c1e92... Initial commit
Switched to branch 'master'

If you want to permanently move back to the previous state and throw away the latest changes, you can issue the following command. This will revert all the commits you have done after this commit.

$ git reset --hard 93c1e   // What happens is that you have changed the master branch to previous commit

Moving files in git

If you need to rename or mv a file in git we perform the following.

$ git mv abc.doc xyz.doc
$ git commit -m "Renaming abc.doc to xyz.doc"

Now say we have a directory called docs in the repository.

$ git mv xyz.doc docs/
$ git commit -m "Moving xyz.doc to abc.doc"

If a file completely be removed from the repository, you issue the following command.

$ git rm -- abc.doc
$ git rm -r -- docs/
$ git commit -m "Removing abc.doc and the docs directory from git"

Say you issued a git rm command, but didn't commit yet. You need the removed file or directory; as previously mentioned

$ git reset HEAD -- abc.doc docs/