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.
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 —
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.
Finally, we’ll summarize here some other changes you might want to be aware of.
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.
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
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.
Trailing whitespaces in
.gitignore files are warned and ignored, unless they are quoted. This change is not backwards compatible.
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.
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?
The Principles of Beautiful Web Design, 4th Edition
Learn PHP in One Day and Learn It Well
Docker for Web Developers