Monday, October 1, 2012

Git 1.8.0-rc0

I just tagged Git 1.8.0-rc0. Tarballs are found at the usual place. The 1.8.0 is scheduled to appear on Oct 21 and I am planning to disappear for a few weeks after that on vacation.

Here are some highlights:
  • In the next major release, we will change the behavior of the "git push" command.  When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics (all your branches were sent to the remote as long as there already are branches of the same name over there).  We will use the "simple" semantics, that pushes the current branch to the branch with the same name only when the current branch is set to integrate with that remote branch.  There is a user preference configuration variable "push.default" to change this, and "git push" will warn about the upcoming change until you set this variable.
  • "git branch --set-upstream" is deprecated and may be removed in a relatively distant future.  "git branch [-u|--set-upstream-to]" has been introduced with a saner order of arguments.
  • The "-Xours" (and "-Xtheirs") backend option to "git merge -s recursive" now takes effect even on binary files.
  • Even during a conflicted merge, "git blame $path" always meant to blame uncommitted changes to the working tree version. The command has been updated to show cleanly merged parts as coming from the other branch that is being merged.
  • "git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order; now it replays them in the order the user told it to, i.e. "A C B", which is what the user naturally expects. 
  • "git log --all-match --grep=A --grep=B" ought to show commits that mention both A and B  but when these three options are used with --author or --committer, it showed commits that mention either A or B (or both) instead; this has been fixed.
  • The interactive prompt "git send-email" gives was error prone. It asked "What e-mail address do you want to use?" with the address it guessed (correctly) the user would want to use in its prompt, tempting the user to say "y". But the response was taken as "No, please use 'y' as my e-mail address instead", which is most certainly not what the user meant; the command asks for confirmation in such a case now.
I've been doing "-rc0" since the Git version 1.5.0 era (that's almost 6 years).

It is easy to understand what "-rc1" is.  It is the first "release candidate". Some last-minute bugs and regressions are expected to be found in it, reported, fixed and will result in "-rc2", "-rc3", etc. until the final release, which hopefully is as close to perfect as we can make.

But what is "-rc0"?

I do not know about other projects, but in the context of Git, it is "a more or less feature complete preview of the upcoming release". There may still be a couple to several topics cooking on the 'next' branch that are to be merged before the real feature freeze ("-rc1"), but they are relatively minor that lacking them is not expected to change the overall end user experience too much from the final release.

And the 1.8.0-rc0 is such a preview. I am planning to merge two small features and two fixes later this week when I tag 1.8.0-rc1, but other than these four topics, what has been tagged today is more or less a good preview for the final release (modulo bugs and regressions that will be fixed, if any, before the real thing).

That means that it is very important for the users to test and find regressions in this preview. If you are using Git, please take some time and do your part to help the upcoming release as polished as we could.