Re: [ANNOUNCE] Git v2.14.0-rc0

2017-07-18 Thread Junio C Hamano
Junio C Hamano  writes:

> 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

2017-07-17 Thread Junio C Hamano
Ævar Arnfjörð Bjarmason  writes:

> 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

2017-07-15 Thread Ævar Arnfjörð Bjarmason

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

2017-07-14 Thread Christian Couder
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/


Re: [ANNOUNCE] Git v2.14.0-rc0

2017-07-14 Thread Ævar Arnfjörð Bjarmason

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

2017-07-13 Thread Junio C Hamano
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