Re: [ANNOUNCE] Git v2.14.0-rc0
Junio C Hamanowrites: > As I shoot for shorter summary, going down to too much detail in > these entries is not welcome. > > However, an exception is the top part of the release notes where we > discuss backward incompatible changes etc. that helps people to > decide the deployment strategy. Encouraging migration from v1 to v2 > belongs there, I would think. I added this at the end of the "Backward compatibility notes" at the beginning of the release notes, and renamed the entire section to "Backward compatibility notes and other notable changes." * Git can now be built with PCRE v2 instead of v1 of the PCRE library. Replace USE_LIBPCRE=YesPlease with USE_LIBPCRE2=YesPlease in existing build scripts to build against the new version. As the upstream PCRE maintainer has abandoned v1 maintenance for all but the most critical bug fixes, use of v2 is recommended. Thanks.
Re: [ANNOUNCE] Git v2.14.0-rc0
Ævar Arnfjörð Bjarmasonwrites: > On Thu, Jul 13 2017, Junio C. Hamano jotted: > > Proposed improvements for the release notes (is this a good way to > propose RelNotes changes?) Thanks. You could also throw a patch just like any bugfix/update to documentation, I would think. > I think this may explain it better: > > * The "[includeIf "gitdir:$dir"] path=..." mechanism introduced in >2.13.0 would canonicalize the path of the gitdir being >matched. > >Therefore it wouldn't match e.g. "gitdir:~/work/*" against a repo in >"~/work/main" if ~/work was a symlink to "/mnt/storage/work". > >Now we match both the resolved canonical path and what "pwd" would >show. The include will happen if either one matches. Will use this (and some others) verbatim ;-) Thanks. >> * Update "perl-compatible regular expression" support to enable JIT >>and also allow linking with the newer PCRE v2 library. > > At the risk of advertising work I've done too much, I think it makes > sense to split this into two separate and somewhat more verbose items: As I shoot for shorter summary, going down to too much detail in these entries is not welcome. However, an exception is the top part of the release notes where we discuss backward incompatible changes etc. that helps people to decide the deployment strategy. Encouraging migration from v1 to v2 belongs there, I would think.
Re: [ANNOUNCE] Git v2.14.0-rc0
On Sat, Jul 15 2017, Christian Couder jotted: > On Sat, Jul 15, 2017 at 1:17 AM, Ævar Arnfjörð Bjarmason >wrote: >> >> On Thu, Jul 13 2017, Junio C. Hamano jotted: > >>> * "git send-email" learned to overcome some SMTP server limitation >>>that does not allow many pieces of e-mails to be sent over a single >>>session. >> >> Makes it sound like it does that automatically, also "pieces of e-mails" >> and "sent over" is odd, maybe: >> >> * "git send-email" now has --batch-size and --relogin-delay options >>which can be used to overcome limitations on SMTP servers that have >>limits on how many of e-mails can be sent in a single session. > > Maybe s/that have limits on how/that restrict how/ Yes that's better. Thanks.
Re: [ANNOUNCE] Git v2.14.0-rc0
On Sat, Jul 15, 2017 at 1:17 AM, Ævar Arnfjörð Bjarmasonwrote: > > On Thu, Jul 13 2017, Junio C. Hamano jotted: >> * "git send-email" learned to overcome some SMTP server limitation >>that does not allow many pieces of e-mails to be sent over a single >>session. > > Makes it sound like it does that automatically, also "pieces of e-mails" > and "sent over" is odd, maybe: > > * "git send-email" now has --batch-size and --relogin-delay options >which can be used to overcome limitations on SMTP servers that have >limits on how many of e-mails can be sent in a single session. Maybe s/that have limits on how/that restrict how/
Re: [ANNOUNCE] Git v2.14.0-rc0
On Thu, Jul 13 2017, Junio C. Hamano jotted: Proposed improvements for the release notes (is this a good way to propose RelNotes changes?) > An early preview release Git v2.14.0-rc0 is now available for > testing at the usual places. It is comprised of 675 non-merge > commits since v2.13.0, contributed by 53 people, 14 of which are > new faces. > [...] > Git 2.14 Release Notes (draft) > == > > Backward compatibility notes. > > * Use of an empty string as a pathspec element that is used for >'everything matches' is still warned and Git asks users to use a >more explicit '.' for that instead. The hope is that existing >users will not mind this change, and eventually the warning can be >turned into a hard error, upgrading the deprecation into removal of >this (mis)feature. That is not scheduled to happen in the upcoming >release (yet). > > * Git now avoids blindly falling back to ".git" when the setup >sequence said we are _not_ in Git repository. A corner case that >happens to work right now may be broken by a call to die("BUG"). >We've tried hard to locate such cases and fixed them, but there >might still be cases that need to be addressed--bug reports are >greatly appreciated. > > * The experiment to improve the hunk-boundary selection of textual >diff output has finished, and the "indent heuristics" has now >become the default. > > > Updates since v2.13 > --- > > UI, Workflows & Features > > * The colors in which "git status --short --branch" showed the names >of the current branch and its remote-tracking branch are now >configurable. > > * "git clone" learned the "--no-tags" option not to fetch all tags >initially, and also set up the tagopt not to follow any tags in >subsequent fetches. > > * "git archive --format=zip" learned to use zip64 extension when >necessary to go beyond the 4GB limit. > > * "git reset" learned "--recurse-submodules" option. > > * "git diff --submodule=diff" now recurses into nested submodules. > > * "git repack" learned to accept the --threads= option and pass it >to pack-objects. > > * "git send-email" learned to run sendemail-validate hook to inspect >and reject a message before sending it out. > > * There is no good reason why "git fetch $there $sha1" should fail >when the $sha1 names an object at the tip of an advertised ref, >even when the other side hasn't enabled allowTipSHA1InWant. > > * The recently introduced "[includeIf "gitdir:$dir"] path=..." >mechanism has further been taught to take symlinks into account. >The directory "$dir" specified in "gitdir:$dir" may be a symlink to >a real location, not something that $(getcwd) may return. In such >a case, a realpath of "$dir" is compared with the real path of the >current repository to determine if the contents from the named path >should be included. I think this is backwards, comparing the realpath is what we did in 2.13.0, i.e. if ~/work was a symlink to /mnt/storage/wor we'd match "gitdir:~/work against /mnt/storage/work only (the realpath), now we also match it against the `pwd` ~/git_tree. This also makes it sound like now we just do it differently, whereas we do both now. I think this may explain it better: * The "[includeIf "gitdir:$dir"] path=..." mechanism introduced in 2.13.0 would canonicalize the path of the gitdir being matched. Therefore it wouldn't match e.g. "gitdir:~/work/*" against a repo in "~/work/main" if ~/work was a symlink to "/mnt/storage/work". Now we match both the resolved canonical path and what "pwd" would show. The include will happen if either one matches. > * Make the "indent" heuristics the default in "diff" and > diff.indentHeuristics >configuration variable an escape hatch for those who do no want it. It's "diff.indentHeuristic" not "diff.indentHeuristics" (extra "s"). The "and diff.indentHeuristics configuration variable" reads strangely to me. Maybe this, and also explain what it's for (the explanation may be shitty): * Make the "indent" heuristics the default in "diff". The diff.indentHeuristic configuration variable can be set to "false" or --no-indent-heuristic can be provided on the command-line for those who do not want it. The common case affected by the indent heuristic is to make diffs that deal with editing the middle of repetitive code look nicer, since they don't seem to e.g. "steal" parts of an earlier function definition for their own use. > * Many commands learned to pay attention to submodule.recurse >configuration. > > * The convention for a command line is to follow "git cmdname >--options" with revisions followed by an optional "--" >disambiguator and then finally pathspecs. When "--" is not there, >we make sure early ones are all interpretable as revs (and do not >look like paths) and later ones are the
[ANNOUNCE] Git v2.14.0-rc0
An early preview release Git v2.14.0-rc0 is now available for testing at the usual places. It is comprised of 675 non-merge commits since v2.13.0, contributed by 53 people, 14 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.14.0-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://github.com/gitster/git New contributors whose contributions weren't in v2.13.0 are as follows. Welcome to the Git development community! A. Wilcox, Ben Peart, Brian Malehorn, James Clarke, Jeff Smith, Kaartic Sivaraam, Liam Beguin, Phillip Wood, Rikard Falkeborn, Sahil Dua, Samuel Lijin, Stephen Kent, Tyler Brazier, and xiaoqiang zhao. Returning contributors who helped this release are as follows. Thanks for your continued support. Adam Dinwoodie, Ævar Arnfjörð Bjarmason, Alejandro R. Sedeño, Andreas Heiduk, Beat Bolli, Brandon Williams, brian m. carlson, Christian Couder, David Aguilar, David Turner, Dennis Kaarsemaker, Eric Wong, Jean-Noel Avila, Jeff Hostetler, Jeff King, Johannes Schindelin, Johannes Sixt, Jonathan Nieder, Jonathan Tan, Junio C Hamano, Kyle J. McKay, Kyle Meyer, Lars Schneider, Marc Branchaud, Michael Haggerty, Mike Hommey, Nguyễn Thái Ngọc Duy, Patrick Steinhardt, Prathamesh Chavan, Ralf Thielow, Ramsay Jones, René Scharfe, Stefan Beller, Štěpán Němec, Sven Strickroth, SZEDER Gábor, Thomas Gummerer, Torsten Bögershausen, and Ville Skyttä. Git 2.14 Release Notes (draft) == Backward compatibility notes. * Use of an empty string as a pathspec element that is used for 'everything matches' is still warned and Git asks users to use a more explicit '.' for that instead. The hope is that existing users will not mind this change, and eventually the warning can be turned into a hard error, upgrading the deprecation into removal of this (mis)feature. That is not scheduled to happen in the upcoming release (yet). * Git now avoids blindly falling back to ".git" when the setup sequence said we are _not_ in Git repository. A corner case that happens to work right now may be broken by a call to die("BUG"). We've tried hard to locate such cases and fixed them, but there might still be cases that need to be addressed--bug reports are greatly appreciated. * The experiment to improve the hunk-boundary selection of textual diff output has finished, and the "indent heuristics" has now become the default. Updates since v2.13 --- UI, Workflows & Features * The colors in which "git status --short --branch" showed the names of the current branch and its remote-tracking branch are now configurable. * "git clone" learned the "--no-tags" option not to fetch all tags initially, and also set up the tagopt not to follow any tags in subsequent fetches. * "git archive --format=zip" learned to use zip64 extension when necessary to go beyond the 4GB limit. * "git reset" learned "--recurse-submodules" option. * "git diff --submodule=diff" now recurses into nested submodules. * "git repack" learned to accept the --threads= option and pass it to pack-objects. * "git send-email" learned to run sendemail-validate hook to inspect and reject a message before sending it out. * There is no good reason why "git fetch $there $sha1" should fail when the $sha1 names an object at the tip of an advertised ref, even when the other side hasn't enabled allowTipSHA1InWant. * The recently introduced "[includeIf "gitdir:$dir"] path=..." mechanism has further been taught to take symlinks into account. The directory "$dir" specified in "gitdir:$dir" may be a symlink to a real location, not something that $(getcwd) may return. In such a case, a realpath of "$dir" is compared with the real path of the current repository to determine if the contents from the named path should be included. * Make the "indent" heuristics the default in "diff" and diff.indentHeuristics configuration variable an escape hatch for those who do no want it. * Many commands learned to pay attention to submodule.recurse configuration. * The convention for a command line is to follow "git cmdname --options" with revisions followed by an optional "--" disambiguator and then finally pathspecs. When "--" is not there, we make sure early ones are all interpretable as revs (and do not look like paths) and later ones are the other way around. A pathspec with "magic" (e.g. ":/p/a/t/h" that matches p/a/t/h from the top-level of the working tree, no matter what subdirectory you are working from) are conservatively judged as "not a path", which required disambiguation more