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
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.
Shaumik is a data analyst by day, and a comic book enthusiast by night (or maybe, he's Batman?) Shaumik has been writing tutorials and creating screencasts for over five years. When not working, he's busy automating mundane daily tasks through meticulously written scripts!