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.

Git 2.0

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

What are the major improvements in Git 2.0 compared to its previous versions?

Git 2.0 comes with several significant improvements over its previous versions. One of the most notable changes is the introduction of a more intuitive and user-friendly behavior of “git push”. In previous versions, “git push” would update all matching branches with the same name in the remote repository. However, in Git 2.0, “git push” only updates the current branch. This change reduces the risk of unintentionally overwriting changes.

Another major improvement is the enhanced performance of “git fetch” and “git pull”. Git 2.0 introduces a new feature called “bitmap indexes” that significantly speeds up these operations, especially in large repositories.

How can I install Git 2.0 on my Windows machine?

To install Git 2.0 on a Windows machine, you need to download the Git for Windows installer from the official Git website. Once the installer is downloaded, run it and follow the on-screen instructions. During the installation process, you can choose the components you want to install and configure your Git settings. After the installation is complete, you can verify the installation by opening a command prompt and typing “git –version”. This command should return the installed version of Git.

What is the “protocol v2” in Git 2.0?

The “protocol v2” is a new network fetch protocol introduced in Git 2.0. This protocol improves the performance of “git fetch” operations by reducing the amount of data transferred between the client and the server. In the new protocol, the server first sends a list of all the branches and tags in the repository, and then the client selects the ones it needs. This approach is more efficient than the old protocol, where the server would send all the branches and tags, regardless of whether the client needs them or not.

Where can I find the release notes for Git 2.0?

The release notes for Git 2.0 can be found in the official Git repository on GitHub. The release notes provide detailed information about all the new features, improvements, and bug fixes in Git 2.0. They also include a list of contributors who helped develop this version.

How does the new “git push” behavior in Git 2.0 affect my workflow?

The new “git push” behavior in Git 2.0 can make your workflow more efficient and less error-prone. In previous versions of Git, “git push” would update all matching branches in the remote repository, which could lead to unintentional overwrites. In Git 2.0, “git push” only updates the current branch, reducing the risk of overwriting changes. This change means that you need to be more explicit when you want to push changes to multiple branches, but it also gives you more control over what gets pushed to the remote repository.