What’s New in Git 2.0?

Key Takeaways

• Git 2.0 has introduced a change in the default behavior for ‘git push’, which now only pushes the current branch to the remote branch with the same name, rather than pushing all local branches with matching remote branches.
• Changes to ‘git add’ in Git 2.0 include the ability to notice and stage removed files for commit, and the ‘git add -u’ command now being a tree-wide operation, adding changed files throughout the whole repository regardless of where the command is run.
• Other changes in Git 2.0 include a new configuration variable for ‘git pull’, changes to where remote tracking branches for ‘git svn’ are created, warnings for trailing whitespaces in .gitignore files, new options for ‘git grep’, and the removal of remote helper interfaces for Mercurial and Bazaar.

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?

Frequently Asked Questions about Git 2.0