undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update draft release notes to 1.6.6 before merging topics for -rc1

Browse Source 
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Junio C Hamano 2009-11-28 11:13:59 -08:00
parent 7fc9d1526e
commit 66abce05dd
1 changed files with 94 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

121
Documentation/RelNotes-1.6.6.txt
View File

@ -1,39 +1,97 @@
Git v1.6.6 Release Notes
========================
In this release, "git fsck" defaults to "git fsck --full" and checks
packfiles, and because of this it will take much longer to complete
than before. If you prefer a quicker check only on loose objects (the
old default), you can say "git fsck --no-full". This has been
supported by 1.5.4 and newer versions of git, so it is safe to write
it in your script even if you use slightly older git on some of your
machines.
Notes on behaviour change
-------------------------
In git 1.7.0, which is planned to be the release after 1.6.6, "git
push" into a branch that is currently checked out will be refused by
default.
* In this release, "git fsck" defaults to "git fsck --full" and
checks packfiles, and because of this it will take much longer to
complete than before. If you prefer a quicker check only on loose
objects (the old default), you can say "git fsck --no-full". This
has been supported by 1.5.4 and newer versions of git, so it is
safe to write it in your script even if you use slightly older git
on some of your machines.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyCurrentBranch in the receiving
repository.
Preparing yourselves for compatibility issues in 1.7.0
------------------------------------------------------
Also, "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.
In git 1.7.0, which is planned to be the release after 1.6.6, there will
be a handful of behaviour changes that will break backward compatibility.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyDeleteCurrent in the receiving
repository.
These changes were discussed long time ago and existing behaviours have
been identified as more problematic to the userbase than keeping them for
the sake of backward compatibility.
To ease the transition plan, the receiving repository of such a
push running this release will issue a big warning when the
configuration variable is missing. Please refer to:
When necessary, transition strategy for existing users has been designed
not to force them running around setting configuration variables and
updating their scripts in order to keep the traditional behaviour 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 transtion period, and
ended up panicking on the day their sysadmins updated their git.
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
For changes decided to be in 1.7.0, we have been much louder to strongly
discourage such procrastination. If you have been using recent versions
of git, you would have already seen warnings issued when you exercised
features whose behaviour will change, with the instruction on how to keep
the existing behaviour if you choose to. You hopefully should be well
prepared already.
Of course, we have also given "this and that will change in 1.7.0; prepare
yourselves" warnings in the release notes and announcement messages.
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 them
without setting the configuration, so repositories of people who
still need to be able to perform such a push should already 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. It has been possible
to configure send-email to do this by setting sendemail.chainreplyto
configuration variable to false. The only thing the new 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 behaviour 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 behaviour 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.
for more details on the reason why this change is needed and the
transition plan.
Updates since v1.6.5
--------------------
@ -76,6 +134,12 @@ Updates since v1.6.5
* "git diff" learned --submodule option to show a list of one-line logs
instead of differences between the commit object names.
* "git fetch" learned --all and --multiple options, to run fetch from
many repositories, and --prune option to remove remote tracking
branches that went stale. These make "git remote update" and "git
remote prune" less necessary (there is no plan to remove "remote
update" nor "remote prune", though).
* "git fsck" by default checks the packfiles (i.e. "--full" is the
default); you can turn it off with "git fsck --no-full".
@ -88,6 +152,9 @@ Updates since v1.6.5
* "git log --decorate" shows the location of HEAD as well.
* "git log" and "git rev-list" learned to take revs and pathspecs from
the standard input with the new "--stdin" option.
* "--pretty=format" option to "log" family of commands learned:
. to wrap text with the "%w()" specifier.
@ -125,5 +192,5 @@ release, unless otherwise noted.
---
exec >/var/tmp/1
echo O=$(git describe master)
O=v1.6.5.3-337-gf341feb
O=v1.6.6-rc0-62-g7fc9d15
git shortlog --no-merges $O..master --not maint