Re: [ANNOUNCE] Git v1.8.2-rc0
Junio C Hamano gits...@pobox.com writes: Git v1.8.2 Release Notes (draft) Backward compatibility notes In the upcoming major release (tentatively called 1.8.2), 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 I don't understand: wasn't this supposed to happen in Git 2.0? Did you mean In the upcoming major release (tentatively called *2.0*)? Also, you may want to mention the argumentless git add -u change too. It currently has an item below, but this is a future backward-incompatible change so it may deserve to appear in this section too. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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.2-rc0
On 2013-02-17 16:52, Junio C Hamano wrote: * Color specifiers, e.g. %C(blue)Hello%C(reset), used in the --format= option of git log and friends can be disabled when the output is not sent to a terminal by prefixing them with auto,, e.g. %C(auto,blue)Hello%C(auto,reset). Thanks so much! It has long annoyed me that I had to maintain pairs of nigh-identical aliases, one with colors for output on my terminal, the other alias uncolored for piping to further commands. -tkc -- 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.2-rc0
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: Git v1.8.2 Release Notes (draft) Backward compatibility notes In the upcoming major release (tentatively called 1.8.2), 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 I don't understand: wasn't this supposed to happen in Git 2.0? Did you mean In the upcoming major release (tentatively called *2.0*)? Thanks. I am not sure what I was thinking. Perhaps when we started this cycle we did want to merge the push-2.0-default-to-simple series Will update. Also, you may want to mention the argumentless git add -u change too. It currently has an item below, but this is a future backward-incompatible change so it may deserve to appear in this section too. Quite right. Care to do the honors as the proposer to the new direction? -- 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.2-rc0
Junio C Hamano gits...@pobox.com writes: I don't understand: wasn't this supposed to happen in Git 2.0? Did you mean In the upcoming major release (tentatively called *2.0*)? Thanks. I am not sure what I was thinking. Perhaps when we started this cycle we did want to merge the push-2.0-default-to-simple series Will update. Also, you may want to mention the argumentless git add -u change too. It currently has an item below, but this is a future backward-incompatible change so it may deserve to appear in this section too. OK, let's do this. Thanks for sharp eyes. Documentation/RelNotes/1.8.2.txt | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/Documentation/RelNotes/1.8.2.txt b/Documentation/RelNotes/1.8.2.txt index a5a1d4e..a287f24 100644 --- a/Documentation/RelNotes/1.8.2.txt +++ b/Documentation/RelNotes/1.8.2.txt @@ -4,8 +4,8 @@ Git v1.8.2 Release Notes Backward compatibility notes -In the upcoming major release (tentatively called 1.8.2), we will -change the behavior of the git push command. +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 @@ -22,6 +22,18 @@ 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 ref under refs/tags/ hierarchy will fail, without --force. +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 +scope of the operation has always been limited to the subirectory. +Many users found this counter-intuitive, given that git commit -a +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 +encourage the user to say git add -u/-A . instead when restricting +the scope to the current directory. At Git 2.0 (not *this* one), we +plan to change these commands without pathspec to operate on the +entire tree, and training your fingers to type . will protect you +against the future change. + Updates since v1.8.1 -- 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.2-rc0
Junio C Hamano gits...@pobox.com writes: +At Git 2.0 (not *this* one), we +plan to change these commands without pathspec to operate on the +entire tree, and training your fingers to type . will protect you +against the future change. My understanding of the plan was more to forbid argumentless git -u|-A at Git 2.0 (this is the potentially harmful change), and then to re-allow it with different semantics later. But I'm OK with changing directly too, as long as we have warned for some time before, and will continue to warn after for some time too. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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.2-rc0
An early preview Git v1.8.2-rc0 for the upcoming release is now available for testing at the usual places. The preview includes contributions from 80+ people, totaling some 570+ no-merge changes since v1.8.1 and should give you more or less a complete picture of what the upcoming 1.8.2 would look like. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 3d19b5bc224a7a3427b21c4587c4ab342435e8b6 git-1.8.2.rc0.tar.gz 77dcebd8856cb6c8600dcf2a56ca3554aef9866f git-htmldocs-1.8.2.rc0.tar.gz 26a75c32c75ed05939c13684581698f2daa0feae git-manpages-1.8.2.rc0.tar.gz Also the following public repositories all have a copy of the v1.8.2-rc0 tag and the master branch that the tag points at: 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.2 Release Notes (draft) Backward compatibility notes In the upcoming major release (tentatively called 1.8.2), 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 that already exists in the repository $there, if the rewritten tag you are pushing points at a commit that is a decendant of a commit 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 ref under refs/tags/ hierarchy will fail, without --force. Updates since v1.8.1 UI, Workflows Features * Initial ports to QNX and z/OS UNIX System Services have started. * Output from the tests is coloured using green is okay, yellow is questionable, red is bad and blue is informative scheme. * Mention of GIT/Git/git in the documentation have been updated to be more uniform and consistent. The name of the system and the concept it embodies is Git; the command the users type is git. All-caps GIT was merely a way to imitate Git typeset in small caps in our ASCII text only documentation and to be avoided. * The completion script (in contrib/completion) used to let the default completer to suggest pathnames, which gave too many irrelevant choices (e.g. git add would not want to add an unmodified path). It learnt to use a more git-aware logic to enumerate only relevant ones. * In bare repositories, git shortlog and other commands now read mailmap files from the tip of the history, to help running these tools in server settings. * Color specifiers, e.g. %C(blue)Hello%C(reset), used in the --format= option of git log and friends can be disabled when the output is not sent to a terminal by prefixing them with auto,, e.g. %C(auto,blue)Hello%C(auto,reset). * Scripts can ask Git that wildcard patterns in pathspecs they give do not have any significance, i.e. take them as literal strings. * The patterns in .gitignore and .gitattributes files can have **/, as a pattern that matches 0 or more levels of subdirectory. E.g. foo/**/bar matches bar in foo itself or in a subdirectory of foo. * When giving arguments without -- disambiguation, object names that come earlier on the command line must not be interpretable as pathspecs and pathspecs that come later on the command line must not be interpretable as object names. This disambiguation rule has been tweaked so that :/ (no other string before or after) is always interpreted as a pathspec; git cmd -- :/ is no longer needed, you can just say git cmd :/. * Various hint lines Git gives when it asks the user to edit messages in the editor are commented out with '#' by default. The core.commentchar configuration variable can be used to customize this '#' to a different character. * git add -u and git add -A without pathspec issues warning to make users aware that they are only operating on paths inside the subdirectory they are in. Use :/ (everything from the top) or . (everything from the $cwd) to disambiguate. * git blame (and git diff) learned the --no-follow option. * git branch now rejects some nonsense combinations of command line arguments (e.g. giving more than one branch name to rename) with more case-specific error messages. * git check-ignore command to help debugging .gitignore files has been added. * git
