On the primary development front, we now have the first release candidate 1.8.0-rc1. The final 1.8.0 is scheduled to be tagged on October 21st, 2012, and I'll disappear for a couple of weeks after that, so please help us find the last minute regressions and fix them, if any, in the coming two weeks.
The upcoming release consists of a finely balanced mix of bug-fixes, usability enhancements and surprising new features.
Some highlights:
- In the next major release (not the 1.8.0 release, but the one that follows it, perhaps 1.9 or 2.0), we will change the behavior of the "git push" command. When "git push [$there]" does not say what to push, we have traditionally used the "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 but 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 in 1.8.0 release, "git push" will start warning qabout the upcoming change until you set this variable. - When "git am" is fed an input that has multiple "Content-type: ..." header, it did not grok charset= attribute correctly. It also mishandled a patch attached as application/octet-stream (e.g. not text/*); Content-Transfer-Encoding (e.g. base64) was not honored correctly.
- 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 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.
- "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.
- A repository created with "git clone --single" had its fetch refspecs set up just like a clone without "--single", leading the subsequent "git fetch" to slurp all the other branches, defeating the whole point of specifying "only this branch" in the first place.
- "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.
- "git log -g" can be given "--grep-reflog=pattern" option to look for entries with strings that match the given pattern.
- The "-Xours" (and "-Xtheirs") backend option to "git merge -s recursive" now takes effect even on binary files.
- The sub-command in "git remote" to remove a defined remote was "rm" and the command did not take a fully-spelled "remove".
- 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.
Again, please help us find the last minute regressions and fix them, if any, in the coming two weeks.
Thanks.