kernel
/
git
mirror of https://git.kernel.org/pub/scm/git/git.git
1
0
Fork 0
Code Releases Activity

Update draft release notes to 1.8.2 

Split the backward-compatibility notes into two sections, the ones
that affect this release, and the other to describe changes meant
for Git 2.0.  The latter gives a context to understand why the
changes for this release is necessary.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
maint
Junio C Hamano 2013-03-08 14:14:27 -08:00
parent aadb70a559
commit 3e714cdbab
1 changed files with 33 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
Documentation/RelNotes/1.8.2.txt
View File

@ -1,19 +1,8 @@
Git v1.8.2 Release Notes Git v1.8.2 Release Notes
======================== ========================


Backward compatibility notes Backward compatibility notes (this release)
---------------------------- -------------------------------------------

In the next major release Git 2.0 (not *this* one), 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 so far (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.


"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3 "git push $there tag v1.2.3" used to allow replacing a tag v1.2.3
that already exists in the repository $there, if the rewritten tag that already exists in the repository $there, if the rewritten tag
@ -22,22 +11,41 @@ that the old tag v1.2.3 points at. This was found to be error prone
and starting with this release, any attempt to update an existing and starting with this release, any attempt to update an existing
ref under refs/tags/ hierarchy will fail, without "--force". ref under refs/tags/ hierarchy will fail, without "--force".


When "git add -u" and "git add -A", that does not specify what paths When "git add -u" and "git add -A" that does not specify what paths
to add on the command line, is run from inside a subdirectory, the to add on the command line is run from inside a subdirectory, the
scope of the operation has always been limited to the subdirectory. scope of the operation has always been limited to the subdirectory.
Many users found this counter-intuitive, given that "git commit -a" Many users found this counter-intuitive, given that "git commit -a"
and other commands operate on the entire tree regardless of where you and other commands operate on the entire tree regardless of where you
are. In this release, these commands give warning in such a case and are. In this release, these commands give a warning message that
encourage the user to say "git add -u/-A ." instead when restricting suggests the users to use "git add -u/-A ." when they want to limit
the scope to the current directory. the scope to the current directory; doing so will squelch the message,
while training their fingers.


At Git 2.0 (not *this* one), we plan to change these commands without
pathspec to operate on the entire tree. Forming a habit to type "." Backward compatibility notes (for Git 2.0)
when you mean to limit the command to the current working directory ------------------------------------------
will protect you against the planned future change, and that is the
whole point of the new message (there will be no configuration When "git push [$there]" does not say what to push, we have used the
variable to squelch this warning---it goes against the "habit forming" traditional "matching" semantics so far (all your branches were sent
objective). to the remote as long as there already are branches of the same name
over there). In Git 2.0, the default will change to 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. If you are an old-timer who is used
to the "matching" semantics, you can set it to "matching" to keep the
traditional behaviour. If you want to live in the future early,
you can set it to "simple" today without waiting for Git 2.0.

When "git add -u" and "git add -A", that does not specify what paths
to add on the command line is run from inside a subdirectory, these
commands will operate on the entire tree in Git 2.0 for consistency
with "git commit -a" and other commands. Because there will be no
mechanism to make "git add -u" behave as if "git add -u .", it is
important for those who are used to "git add -u" (without pathspec)
updating the index only for paths in the current subdirectory to start
training their fingers to explicitly say "git add -u ." when they mean
it before Git 2.0 comes.




Updates since v1.8.1 Updates since v1.8.1