Re: [ANNOUNCE] Git v1.8.4
On Tue, 27 Aug 2013, Duy Nguyen wrote: > On Tue, Aug 27, 2013 at 7:06 AM, Nicolas Pitre wrote: > > Yes, after being vaporware for many many years (I don't even remember > > when I started making references to a possible pack format version 4 -- > > certainly more than 6 years ago) I finally completed the code to produce > > a new pack format I'm actually happy with. > > > > ... > > > > But the biggest gain will come from direct interpretation of the native > > pack data encoding. However I'll let others do that part, as well as > > the required fsck support and all the backward compatibility handling, > > etc. Now that the encoding design is pretty much settled I think it is > > good for review, and for others to get involved as well. > > > > Interested? ;-) > > A clone url, or a patch series please! :-) This is coming next. Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.4
Nicolas Pitre writes: > On Fri, 23 Aug 2013, Junio C Hamano wrote: > >> The latest feature release Git v1.8.4 is now available at the usual >> places. It contains 870+ changes from ~100 contributors (among >> which 33 people are new) since v1.8.3. >> >> We will have two more releases til the end of this year; the release >> after that could be Git 2.0. > > May I land a big teaser for a possible Git 2.0 feature? ;-) It is not even any remotely controversial feature that has to wait until 2.0 boundary to potentially break established usage aka inertia. Happy. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.4
On Tue, Aug 27, 2013 at 7:06 AM, Nicolas Pitre wrote: > Yes, after being vaporware for many many years (I don't even remember > when I started making references to a possible pack format version 4 -- > certainly more than 6 years ago) I finally completed the code to produce > a new pack format I'm actually happy with. > > ... > > But the biggest gain will come from direct interpretation of the native > pack data encoding. However I'll let others do that part, as well as > the required fsck support and all the backward compatibility handling, > etc. Now that the encoding design is pretty much settled I think it is > good for review, and for others to get involved as well. > > Interested? ;-) A clone url, or a patch series please! :-) -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.8.4
On Fri, 23 Aug 2013, Junio C Hamano wrote: > The latest feature release Git v1.8.4 is now available at the usual > places. It contains 870+ changes from ~100 contributors (among > which 33 people are new) since v1.8.3. > > We will have two more releases til the end of this year; the release > after that could be Git 2.0. May I land a big teaser for a possible Git 2.0 feature? Here's some cues: $ cd git $ git describe v1.8.4 $ ls -l .git/objects/pack/ total 44240 -r--r--r-- 1 nico nico 4535112 Aug 26 17:16 pack-b04833b53befec3e6cb459fd72ade62c310a0a0e.idx -r--r--r-- 1 nico nico 40762151 Aug 26 17:16 pack-b04833b53befec3e6cb459fd72ade62c310a0a0e.pack $ git packv4-create Usage: git-packv4-create $ mkdir test $ git packv4-create .git/objects/pack/pack-b04833b53befec3e6cb459fd72ade62c310a0a0e test/foo Scanning objects: 100% (161930/161930), done. Writing objects: 100% (161930/161930), done. $ ls -l test total 31952 -rw--- 1 nico nico 1296512 Aug 26 19:28 foo.idx -rw--- 1 nico nico 31420190 Aug 26 19:28 foo.pack [...] $ cd linux $ git describe v3.11-rc7 $ ls -l .git/objects/pack/ total 756068 -r--r--r-- 1 nico nico 88195164 Aug 26 17:25 pack-7fe7cd3b8af810808649d114a11b8aab1f7c5ae9.idx -r--r--r-- 1 nico nico 686006356 Aug 26 17:25 pack-7fe7cd3b8af810808649d114a11b8aab1f7c5ae9.pack $ mkdir test $ git packv4-create .git/objects/pack/pack-7fe7cd3b8af810808649d114a11b8aab1f7c5ae9 test/foo Scanning objects: 100% (3149789/3149789), done. Writing objects: 100% (3149789/3149789), done. $ ls -l test total 597016 -rw--- 1 nico nico 25199384 Aug 26 19:41 foo.idx -rw--- 1 nico nico 586134328 Aug 26 19:41 foo.pack Yes, after being vaporware for many many years (I don't even remember when I started making references to a possible pack format version 4 -- certainly more than 6 years ago) I finally completed the code to produce a new pack format I'm actually happy with. Hundreds of hours went into this work over the years. Lots of head scratching, many dead ends and scrapped attempts. What didn't help is the fact that I never had much time to dedicate to this project. Significant portions of the surviving code were even written when I was on vacation in the Carabeans. And even when it finally worked, the required code cleanup work was impressive. Note this is the pack _creation_ code only. Nothing is able to read this pack format just yet. What I'm willing to do is a simple compatibility layer that recreates the canonical object representation when accessed. This should already make runtime Git significantly faster when performing graph traversal. But the biggest gain will come from direct interpretation of the native pack data encoding. However I'll let others do that part, as well as the required fsck support and all the backward compatibility handling, etc. Now that the encoding design is pretty much settled I think it is good for review, and for others to get involved as well. Interested? ;-) Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.8.4
The latest feature release Git v1.8.4 is now available at the usual places. It contains 870+ changes from ~100 contributors (among which 33 people are new) since v1.8.3. We will have two more releases til the end of this year; the release after that could be Git 2.0. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 2a361a2d185b8bc604f7f2ce2f502d0dea9d3279 git-1.8.4.tar.gz f130398eb623c913497ef51a6e61d916fe7e31c8 git-htmldocs-1.8.4.tar.gz 8c67a7bc442d6191bc17633c7f2846c71bda71cf git-manpages-1.8.4.tar.gz The following public repositories all have a copy of the v1.8.4 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Also, http://www.kernel.org/pub/software/scm/git/ has copies of the release tarballs. Git v1.8.4 Release Notes Backward compatibility notes (for Git 2.0) -- 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). In Git 2.0, the default will change to the "simple" semantics that pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the 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 the variable 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") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. Updates since v1.8.3 Foreign interfaces, subsystems and ports. * Cygwin port has been updated for more recent Cygwin 1.7. * "git rebase -i" now honors --strategy and -X options. * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has been updated to kick in not just when talking http/https but also imap(s) and smtp. * Remote transport helper has been updated to report errors and maintain ref hierarchy used to keep track of its own state better. * With "export" remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run; these problematic cases are disabled for now. * git-remote-hg/bzr (in contrib/) updates. * git-remote-mw (in contrib/) hints users to check the certificate, when https:// connection failed. * git-remote-mw (in contrib/) adds a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. UI, Workflows & Features * Sample "post-receive-email" hook script got an enhanced replacement "multimail" (in contrib/). * Also in contrib/ is a new "contacts" script that runs "git blame" to find out the people who may be interested in a set of changes. * "git clean" command learned an interactive mode. * The "--head" option to "git show-ref" was only to add
Re: [ANNOUNCE] Git v1.8.4-rc4
On Aug 19, 2013, at 12:59, Junio C Hamano wrote: Performance, Internal Implementation, etc. * On Cygwin, we used to use our own lstat(2) emulation that is allegedly faster than the platform one in codepaths where some of the information it returns did not matter, but it started to bite us in a few codepaths where the trick it uses to cheat does show breakages. This emulation has been removed and we use the native lstat(2) emulation supplied by Cygwin now. * The function attributes extensions are used to catch mistakes in use of our own variadic functions that use NULL sentinel at the end (i.e. like execl(3)) and format strings (i.e. like printf(3)). * The code to allow configuration data to be read from in-tree blob objects is in. This may help working in a bare repository and submodule updates. * Fetching between repositories with many refs employed O(n^2) algorithm to match up the common objects, which has been corrected. * The original way to specify remote repository using .git/branches/ used to have a nifty feature. The code to support the feature was still in a function but the caller was changed not to call it 5 years ago, breaking that feature and leaving the supporting code unreachable. The dead code has been removed. * "git pack-refs" that races with new ref creation or deletion have been susceptible to lossage of refs under right conditions, which has been tightened up. * We read loose and packed rerferences in two steps, but after ^^ deciding to read a loose ref but before actually opening it to read s/rerferences/references/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.8.4-rc4
A release candidate Git v1.8.4-rc4 is now available for testing at the usual places. The only changes since -rc3 are reversion of two topics that introduced regressions. Hopefully the final at the end of this week and then we will start the next cycle, most likely to be for 1.8.5. This is a bit delayed than I planned early last week, but sometimes real life happens. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: f390da8ea032c92c673d4cc6c4d8818379db344d git-1.8.4.rc4.tar.gz 90a9df6b2ada9a0ab9c8711e03d77244e7310c1e git-htmldocs-1.8.4.rc4.tar.gz 4e6ed2c0307ba538257bdc9f233dd574b419f411 git-manpages-1.8.4.rc4.tar.gz The following public repositories all have a copy of the v1.8.4-rc4 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.4 Release Notes (draft) Backward compatibility notes (for Git 2.0) -- 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). In Git 2.0, the default will change to the "simple" semantics that pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the 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 the variable 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") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. Updates since v1.8.3 Foreign interfaces, subsystems and ports. * Cygwin port has been updated for more recent Cygwin 1.7. * "git rebase -i" now honors --strategy and -X options. * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has been updated to kick in not just when talking http/https but also imap(s) and smtp. * Remote transport helper has been updated to report errors and maintain ref hierarchy used to keep track of its own state better. * With "export" remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run; these problematic cases are disabled for now. * git-remote-hg/bzr (in contrib/) updates. * git-remote-mw (in contrib/) hints users to check the certificate, when https:// connection failed. * git-remote-mw (in contrib/) adds a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. UI, Workflows & Features * Sample "post-receive-email" hook script got an enhanced replacement "multimail" (in contrib/). * Also in contrib/ is a new "contacts" script that runs "git blame" to find out the people who may be interested in a set of changes. * "git clean" command learned an interactive mode. * The "--head" op
[ANNOUNCE] Git v1.8.4-rc3
A release candidate Git v1.8.4-rc3 is now available for testing at the usual places. Things have calmed down on the 'master' front; we will still need to revert one commit that killed "git stash" in a large directory with a lot of cruft before the final, but other than that, everything else should be pretty much the same as what we will see in the final release. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 4017553f4543c00c392a299b6a67f8ca4ca5e325 git-1.8.4.rc3.tar.gz 1a3a6c6a59df7b60377a0ae86f04b8b0f09e45f4 git-htmldocs-1.8.4.rc3.tar.gz 19281d6fb14e66c5b215bad52e3857418052bfeb git-manpages-1.8.4.rc3.tar.gz The following public repositories all have a copy of the v1.8.4-rc3 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.4 Release Notes (draft) Backward compatibility notes (for Git 2.0) -- 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). In Git 2.0, the default will change to the "simple" semantics that pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the 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 the variable 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") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. Updates since v1.8.3 Foreign interfaces, subsystems and ports. * Cygwin port has been updated for more recent Cygwin 1.7. * "git rebase -i" now honors --strategy and -X options. * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has been updated to kick in not just when talking http/https but also imap(s) and smtp. * Remote transport helper has been updated to report errors and maintain ref hierarchy used to keep track of its own state better. * With "export" remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run; these problematic cases are disabled for now. * git-remote-hg/bzr (in contrib/) updates. * git-remote-mw (in contrib/) hints users to check the certificate, when https:// connection failed. * git-remote-mw (in contrib/) adds a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. UI, Workflows & Features * Sample "post-receive-email" hook script got an enhanced replacement "multimail" (in contrib/). * Also in contrib/ is a new "contacts" script that runs "git blame" to find out the people who may be interested in a set of changes. * "git clean" command learned an interactive mode. * The "--head" option t
[ANNOUNCE] Git v1.8.4-rc2
A release candidate Git v1.8.4-rc2 is now available for testing at the usual places. There are only a handful of small documentation and test updates since -rc1, except one notable change for Cygwin users. We no longer use a custom "fast but cheating" lstat(2) emulation and instead use the platform one. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 1477b3def09d3b10a94441881b1aa19eb7f6586f git-1.8.4.rc2.tar.gz 554ae8d0125c93bfdfa508bbe35a2375c82c545a git-htmldocs-1.8.4.rc2.tar.gz 92a36c67f0def3544bcbd09bced2779142433ba5 git-manpages-1.8.4.rc2.tar.gz The following public repositories all have a copy of the v1.8.4-rc2 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.4 Release Notes (draft) Backward compatibility notes (for Git 2.0) -- 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). In Git 2.0, the default will change to the "simple" semantics that pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the 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 the variable 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") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. Updates since v1.8.3 Foreign interfaces, subsystems and ports. * Cygwin port has been updated for more recent Cygwin 1.7. * "git rebase -i" now honors --strategy and -X options. * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has been updated to kick in not just when talking http/https but also imap(s) and smtp. * Remote transport helper has been updated to report errors and maintain ref hierarchy used to keep track of its own state better. * With "export" remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run; these problematic cases are disabled for now. * git-remote-hg/bzr (in contrib/) updates. * git-remote-mw (in contrib/) hints users to check the certificate, when https:// connection failed. * git-remote-mw (in contrib/) adds a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. UI, Workflows & Features * Sample "post-receive-email" hook script got an enhanced replacement "multimail" (in contrib/). * Also in contrib/ is a new "contacts" script that runs "git blame" to find out the people who may be interested in a set of changes. * "git clean" command learned an interactive mode. * The "--head" option to "git show-ref" was only to add "HEAD" to the list of c
[ANNOUNCE] Git v1.8.4-rc1
A release candidate for Git v1.8.4-rc1 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: ab0bb0ed36dd9c0d6425f64021a9c7d7311a2b5c git-1.8.4.rc1.tar.gz 2d3f1f07ed3bde56fac5e823be7d71bf5bf0f743 git-htmldocs-1.8.4.rc1.tar.gz c21f40d9cd2bbf7c28be4d32a1ae1ad98c198d96 git-manpages-1.8.4.rc1.tar.gz The following public repositories all have a copy of the v1.8.4-rc1 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.4 Release Notes (draft) Backward compatibility notes (for Git 2.0) -- 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). In Git 2.0, the default will change to the "simple" semantics that pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the 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 the variable 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") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. Updates since v1.8.3 Foreign interfaces, subsystems and ports. * Cygwin port has been updated for more recent Cygwin 1.7. * "git rebase -i" now honors --strategy and -X options. * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has been updated to kick in not just when talking http/https but also imap(s) and smtp. * Remote transport helper has been updated to report errors and maintain ref hierarchy used to keep track of its own state better. * With "export" remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run; these problematic cases are disabled for now. * git-remote-hg/bzr (in contrib/) updates. * git-remote-mw (in contrib/) hints users to check the certificate, when https:// connection failed. * git-remote-mw (in contrib/) adds a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. UI, Workflows & Features * Sample "post-receive-email" hook script got an enhanced replacement "multimail" (in contrib/). * Also in contrib/ is a new "contacts" script that runs "git blame" to find out the people who may be interested in a set of changes. * "git clean" command learned an interactive mode. * The "--head" option to "git show-ref" was only to add "HEAD" to the list of candidate refs to be filtered by the usual rules (e.g. "--heads" that only show refs under refs/heads). The meaning of the option has been changed to always show "HEAD" regardless of what filtering will be app
[ANNOUNCE] Git v1.8.4-rc0
A release candidate preview Git v1.8.4-rc0 is now available for testing at the usual places. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 8e0d93653633fcaffc829f607bd8c1077a855c1d git-1.8.4.rc0.tar.gz 1e2b18ea855b3e06ab2e65be90ec57b135d5f4d5 git-htmldocs-1.8.4.rc0.tar.gz bb48a5c81ecdb9a7ce7dde2ea05a2bd37a093cbc git-manpages-1.8.4.rc0.tar.gz The following public repositories all have a copy of the v1.8.4-rc0 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.4 Release Notes (draft) Backward compatibility notes (for Git 2.0) -- 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). In Git 2.0, the default will change to the "simple" semantics that pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the 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 the variable 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") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. Updates since v1.8.3 Foreign interfaces, subsystems and ports. * Cygwin port has been updated for more recent Cygwin 1.7. * "git rebase -i" now honors --strategy and -X options. * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has been updated to kick in not just when talking http/https but also imap(s) and smtp. * Remote transport helper has been updated to report errors and maintain ref hierarchy used to keep track of its own state better. * With "export" remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run; these problematic cases are disabled for now. * git-remote-hg/bzr (in contrib/) updates. * git-remote-mw (in contrib/) hints users to check the certificate, when https:// connection failed. * git-remote-mw (in contrib/) adds a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. UI, Workflows & Features * Sample "post-receive-email" hook script got an enhanced replacement "multimail" (in contrib/). * Also in contrib/ is a new "contacts" script that runs "git blame" to find out the people who may be interested in a set of changes. * "git clean" command learned an interactive mode. * The "--head" option to "git show-ref" was only to add "HEAD" to the list of candidate refs to be filtered by the usual rules (e.g. "--heads" that only show refs under refs/heads). The meaning of the option has been changed to always show "HEAD" regardless of what filtering will be
