What’s New in Git 2.0?
At the end of May, Git’s primary developer, Junio C Hamano, announced on their mailing list the much awaited release of Git 2.0. If you go through the release notes, you will find that there are quite a few changes that have been welcomed by the community.
In this article, I’ll provide an overview of these changes. We will see two big changes that are creating waves, followed by a few miscellaneous ones.
git push
Default Behaviour
If you use Git for your projects, you should know that the general format for pushing code looks like the following:
git push [remote_name] [local_branch]:[remote_branch]
If you are disciplined in your habits and use this syntax, you would not even notice this change in Git. However, if you were lazy and just executed git push
, you would have probably received the following message:
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
In Git 1.x, the default behaviour is set to matching
. This means that all your local branches that have matching branches on the remote are pushed. However, in Git 2.0, the default is changed to simple
, which would push only your current branch to the remote branch with the same name. If you want to continue with matching
, as in 1.x, you can always change the default.
Changes to git add
Git 2.0 brings some changes in the git add
command.
Untracking Removed Files
You would often find the following output on a git status
when you deleted files:
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: my_file1
# deleted: my_file2
In Git 1.x, git add
ignores files that were removed from your repository and you would have to remove them separately. With Git 2.0, git add dir/
will notice removed files and stage the changes for your commit. You can add --ignore-removal
if you want to stage only new or modified files.
git add -u
Regular Git users frequently use the git add -u
command. This command stages the changes in all tracked files for a commit. However, in Git 1.x, one drawback of the commit was that it worked on files within the directory from where the command was run. With Git 2.0, this command is a tree-wide operation, meaning it searches for changed files in your whole repository and adds them, irrespective of where you run the command.
If that’s confusing, let me try to explain with an example. Let’s say you have in your repository two files with changes — README
and src/my_file
. If you change your directory to src
and then run git add -u
, in Git 1.x only my_file
gets added. In Git 2.0, both files are added. If you ran the command from the parent directory, both files are added irrespective of the version.
Miscellaneous Changes
Finally, we’ll summarize here some other changes you might want to be aware of.
git pull
Git pull now has a new configuration variable, pull.ff
, which can be set to allow it to accept only fast forward branches, which eliminates merges, and therefore leads to no conflicts.
git svn
If you use Git with other version control systems, you would probably have come across the command git svn
, which would serve as the base command for all Subversion-related functions.
Remote tracking branches for git svn
were created under refs/remotes
in Git 1.x. However, they will be created under refs/remotes/origin
, which can be changed with the --prefix
option. git svn
is not such a popular feature as most organizations have moved on to Git and this will probably not affect a lot of people.
.gitignore
Files
Trailing whitespaces in .gitignore
files are warned and ignored, unless they are quoted. This change is not backwards compatible.
git grep
The grep
command within Git enabled you to search within all branches. You can now make it behave like a native grep when -h
(no header) and -c
(count) options are given.
Removal of Remote Helper Interfaces
The remote helper interfaces for Mercurial and Bazaar, which were found under contrib/
, are no longer a part of Git and are now maintained as separate repositories as third party plug-ins.
Looking Forward
Git is no doubt the most popular version control management system, and the discussions on HackerNews regarding the release notes proves that. Git 2.0 has its fair share of new features, but so did every version of Git 1.x. There are a few backwards incompatible changes, but they likely will not affect you. If you use Git, the future looks bright. If you don’t, when are you joining the club?