Preparing yourselves for compatibility issues in git 1.7.0

In the release notes of git 1.6.6 an important section was written about the upcoming version 1.7.0
I think it’s important enough to dedicate a separate article on it.

From the release notes:

In git 1.7.0, which is planned to be the release after 1.6.6, there will be a handful of behavior changes that will break backward compatibility.

These changes were discussed long time ago and existing behaviors have been identified as more problematic to the userbase than keeping them for the sake of backward compatibility.

When necessary, a transition strategy for existing users has been designed not to force them running around setting configuration variables and updating their scripts in order to either keep the traditional behavior or adjust to the new behavior, on the day their sysadmin decides to install the new version of git. When we switched from “git-foo” to “git foo” in 1.6.0, even though the change had been advertised and the transition guide had been provided for a very long time, the users procrastinated during the entire transition period, and ended up panicking on the day their sysadmins updated their git installation. We are trying to avoid repeating that unpleasantness in the 1.7.0 release.

For changes decided to be in 1.7.0, commands that will be affected have been much louder to strongly discourage such procrastination, and they continue to be in this release. If you have been using recent versions of git, you would have seen warnings issued when you used features whose behavior will change, with a clear instruction on how to keep the existing behavior if you want to. You hopefully are already well prepared.

Of course, we have also been giving “this and that will change in 1.7.0; prepare yourselves” warnings in the release notes and announcement messages for the past few releases. Let’s see how well users will fare this time.

  • “git push” into a branch that is currently checked out (i.e. pointed by HEAD in a repository that is not bare) will be refused by default.

    Similarly, “git push $there :$killed” to delete the branch $killed in a remote repository $there, when $killed branch is the current branch pointed at by its HEAD, will be refused by default.

    Setting the configuration variables receive.denyCurrentBranch and receive.denyDeleteCurrent to ‘ignore’ in the receiving repository can be used to override these safety features. Versions of git since 1.6.2 have issued a loud warning when you tried to do these operations without setting the configuration, so repositories of people who still need to be able to perform such a push should already have been future proofed.

    Please refer to:

    http://git.or.cz/gitwiki/GitFaq#non-bare
    http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

    for more details on the reason why this change is needed and the transition process that already took place so far.

  • “git send-email” will not make deep threads by default when sending a patch series with more than two messages. All messages will be sent as a reply to the first message, i.e. cover letter. Git 1.6.6 will issue a warning about the upcoming default change, when it uses the traditional “deep threading” behavior as the built-in default. To squelch the warning but still use the “deep threading” behavior, give –chain-reply-to option or set sendemail.chainreplyto to true.

    It has been possible to configure send-email to send “shallow thread” by setting sendemail.chainreplyto configuration variable to false. The only thing 1.7.0 release will do is to change the default when you haven’t configured that variable.

  • “git status” will not be “git commit –dry-run”. This change does not affect you if you run the command without pathspec.

    Nobody sane found the current behavior of “git status Makefile” useful nor meaningful, and it confused users. “git commit –dry-run” has been provided as a way to get the current behavior of this command since 1.6.5.

  • “git diff” traditionally treated various “ignore whitespace” options only as a way to filter the patch output. “git diff –exit-code -b” exited with non-zero status even if all changes were about changing the ammount of whitespace and nothing else. and “git diff -b” showed the “diff –git” header line for such a change without patch text.

    In 1.7.0, the “ignore whitespaces” will affect the semantics of the diff operation itself. A change that does not affect anything but whitespaces will be reported with zero exit status when run with –exit-code, and there will not be “diff –git” header for such a change.

This article is filed under the categories Software » git and has the following tag associated with it: .
There are no comments yet
Skip to the end and leave a comment.

Leave a comment

For questions and/or support consider using the forums.

download