Re: [PATCH] Release notes grammatical fixes.

2014-08-05 Thread Marc Branchaud
On 14-08-05 02:43 PM, Junio C Hamano wrote:
> Junio C Hamano  writes:
> 
>> Marc Branchaud  writes:
>> ...
>>> @@ -87,22 +87,20 @@ UI, Workflows & Features
>>>   * "git mergetool" learned to drive the vimdiff3 backend.
>>>  
>>>   * mergetool.prompt used to default to 'true', always asking "do you
>>> -   really want to run the tool on this path?".  Among the two
>>> -   purposes this prompt serves, ignore the use case to confirm that
>>> -   the user wants to view particular path with the named tool, and
>>> -   redefine the meaning of the prompt only to confirm the choice of
>>> -   the tool made by the autodetection (for those who configured the
>>> -   tool explicitly, the prompt shown for the latter purpose is
>>> -   simply annoying).
>>> -
>>> -   Strictly speaking, this is a backward incompatible change and the
>>> +   really want to run the tool on this path?".  The default has been
>>> +   changed to 'false'.  However, the prompt will still appear if
>>> +   mergetool used its autodetection system to guess which tool to use.
>>> +   Users who explicitly specify or configure a tool will no longer see
>>> +   the prompt by default.
>>> +
>>> +   Strictly speaking, this is a backward incompatible change and
>>> users need to explicitly set the variable to 'true' if they want
>>> -   to resurrect the now-ignored use case.
>>> +   to resurrect the old behaviour.
>>
>> I however think you are losing information here.  It is unclear in
>> the rewritten one why you would ever want the "old" behaviour, i.e.
>> what you may be missing by following along with this change.
> 
> Perhaps this on top of yoru patch?

Yes, I think that's good, thanks.

M.


>  Documentation/RelNotes/2.1.0.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/RelNotes/2.1.0.txt 
> b/Documentation/RelNotes/2.1.0.txt
> index 4fd153e..1b16b12 100644
> --- a/Documentation/RelNotes/2.1.0.txt
> +++ b/Documentation/RelNotes/2.1.0.txt
> @@ -95,7 +95,7 @@ UI, Workflows & Features
>  
> Strictly speaking, this is a backward incompatible change and
> users need to explicitly set the variable to 'true' if they want
> -   to resurrect the old behaviour.
> +   to be prompted to confirm running the tool on each path.
>  
>   * "git replace" learned the "--edit" subcommand to create a
> replacement by editing an existing object.
> 
--
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: [PATCH] Release notes grammatical fixes.

2014-08-05 Thread Junio C Hamano
Junio C Hamano  writes:

> Marc Branchaud  writes:
> ...
>> @@ -87,22 +87,20 @@ UI, Workflows & Features
>>   * "git mergetool" learned to drive the vimdiff3 backend.
>>  
>>   * mergetool.prompt used to default to 'true', always asking "do you
>> -   really want to run the tool on this path?".  Among the two
>> -   purposes this prompt serves, ignore the use case to confirm that
>> -   the user wants to view particular path with the named tool, and
>> -   redefine the meaning of the prompt only to confirm the choice of
>> -   the tool made by the autodetection (for those who configured the
>> -   tool explicitly, the prompt shown for the latter purpose is
>> -   simply annoying).
>> -
>> -   Strictly speaking, this is a backward incompatible change and the
>> +   really want to run the tool on this path?".  The default has been
>> +   changed to 'false'.  However, the prompt will still appear if
>> +   mergetool used its autodetection system to guess which tool to use.
>> +   Users who explicitly specify or configure a tool will no longer see
>> +   the prompt by default.
>> +
>> +   Strictly speaking, this is a backward incompatible change and
>> users need to explicitly set the variable to 'true' if they want
>> -   to resurrect the now-ignored use case.
>> +   to resurrect the old behaviour.
>
> I however think you are losing information here.  It is unclear in
> the rewritten one why you would ever want the "old" behaviour, i.e.
> what you may be missing by following along with this change.

Perhaps this on top of yoru patch?

 Documentation/RelNotes/2.1.0.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt
index 4fd153e..1b16b12 100644
--- a/Documentation/RelNotes/2.1.0.txt
+++ b/Documentation/RelNotes/2.1.0.txt
@@ -95,7 +95,7 @@ UI, Workflows & Features
 
Strictly speaking, this is a backward incompatible change and
users need to explicitly set the variable to 'true' if they want
-   to resurrect the old behaviour.
+   to be prompted to confirm running the tool on each path.
 
  * "git replace" learned the "--edit" subcommand to create a
replacement by editing an existing object.
--
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: [PATCH] Release notes grammatical fixes.

2014-08-05 Thread Junio C Hamano
Marc Branchaud  writes:

> Signed-off-by: Marc Branchaud 
> diff --git a/Documentation/RelNotes/2.1.0.txt 
> b/Documentation/RelNotes/2.1.0.txt

Many are indeed grammatical errors, and many others make the result
easier to read, even if the original weren't incorrect per-se.

> @@ -87,22 +87,20 @@ UI, Workflows & Features
>   * "git mergetool" learned to drive the vimdiff3 backend.
>  
>   * mergetool.prompt used to default to 'true', always asking "do you
> -   really want to run the tool on this path?".  Among the two
> -   purposes this prompt serves, ignore the use case to confirm that
> -   the user wants to view particular path with the named tool, and
> -   redefine the meaning of the prompt only to confirm the choice of
> -   the tool made by the autodetection (for those who configured the
> -   tool explicitly, the prompt shown for the latter purpose is
> -   simply annoying).
> -
> -   Strictly speaking, this is a backward incompatible change and the
> +   really want to run the tool on this path?".  The default has been
> +   changed to 'false'.  However, the prompt will still appear if
> +   mergetool used its autodetection system to guess which tool to use.
> +   Users who explicitly specify or configure a tool will no longer see
> +   the prompt by default.
> +
> +   Strictly speaking, this is a backward incompatible change and
> users need to explicitly set the variable to 'true' if they want
> -   to resurrect the now-ignored use case.
> +   to resurrect the old behaviour.

I however think you are losing information here.  It is unclear in
the rewritten one why you would ever want the "old" behaviour, i.e.
what you may be missing by following along with this change.

Thanks. 
--
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


[PATCH] Release notes grammatical fixes.

2014-08-05 Thread Marc Branchaud
Signed-off-by: Marc Branchaud 
---

(Note that I did not reflow lines to keep them a specific length.)

 Documentation/RelNotes/2.1.0.txt | 108 +++
 1 file changed, 53 insertions(+), 55 deletions(-)

diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt
index 5cfb0ab..4fd153e 100644
--- a/Documentation/RelNotes/2.1.0.txt
+++ b/Documentation/RelNotes/2.1.0.txt
@@ -12,7 +12,7 @@ Backward compatibility notes
  $ git config core.pager "less -S"
 
to restore the traditional behaviour.  It is expected that people
-   find output from the most subcommands easier to read with the new
+   find output from most subcommands easier to read with the new
default, except for "blame" which tends to produce really long
lines.  To override the new default only for "git blame", you can
do this:
@@ -31,7 +31,7 @@ UI, Workflows & Features
default value "FRSX" when we spawn "less" as the pager.  "S" (chop
long lines instead of wrapping) has been removed from this default
set of options, because it is more or less a personal taste thing,
-   as opposed to others that have good justifications (i.e. "R" is
+   as opposed to the others that have good justifications (i.e. "R" is
very much justified because many kinds of output we produce are
colored and "FX" is justified because output we produce is often
shorter than a page).
@@ -39,47 +39,47 @@ UI, Workflows & Features
  * The logic and data used to compute the display width needed for
UTF-8 strings have been updated to match Unicode 7.0 better.
 
- * HTTP-based transports learned to propagate the error messages from
-   the webserver better to the client coming over the HTTP transport.
+ * HTTP-based transports learned to better propagate the error messages from
+   the webserver to the client coming over the HTTP transport.
 
  * The completion script for bash (in contrib/) has been updated to
-   handle aliases that define complex sequence of commands better.
+   better handle aliases that define a complex sequence of commands.
 
- * The "core.preloadindex" configuration variable is by default
-   enabled, allowing modern platforms to take advantage of the
-   multiple cores they have.
+ * The "core.preloadindex" configuration variable is enabled by default,
+   allowing modern platforms to take advantage of their
+   multiple cores.
 
  * "git clone" applies the "if cloning from a local disk, physically
-   copy repository using hardlinks, unless otherwise told not to with
-   --no-local" optimization when url.*.insteadOf mechanism rewrites a
-   "git clone $URL" that refers to a repository over the network to a
+   copy the repository using hardlinks, unless otherwise told not to with
+   --no-local" optimization when the url.*.insteadOf mechanism rewrites a
+   remote-repository "git clone $URL" into a
clone from a local disk.
 
- * "git commit --date=" option learned to read from more
+ * "git commit --date=" option learned more
timestamp formats, including "--date=now".
 
  * The `core.commentChar` configuration variable is used to specify a
-   custom comment character other than the default "#" to be used in
-   the commit log editor.  This can be set to `auto` to attempt to
-   choose a different character that does not conflict with what
-   already starts a line in the message being edited for cases like
+   custom comment character (other than the default "#") for
+   the commit message editor.  This can be set to `auto` to attempt to
+   choose a different character that does not conflict with any that
+   already starts a line in the message being edited, for cases like
"git commit --amend".
 
- * "git format-patch" learned --signature-file= to take the mail
-   signature from.
+ * "git format-patch" learned --signature-file= to add the contents
+   of a file as a signature to the mail message it produces.
 
- * "git grep" learned grep.fullname configuration variable to force
-   "--full-name" to be default.  This may cause regressions on
-   scripted users that do not expect this new behaviour.
+ * "git grep" learned the grep.fullname configuration variable to force
+   "--full-name" to be the default.  This may cause regressions for
+   scripted users who do not expect this new behaviour.
 
  * "git imap-send" learned to ask the credential helper for auth
material.
 
- * "git log" and friends now understand the value "auto" set to the
+ * "git log" and friends now understand the value "auto" for the
"log.decorate" configuration variable to enable the "--decorate"
option automatically when the output is sent to tty.
 
- * "git merge" without argument, even when there is an upstream
+ * "git merge" without an argument, even when there is an upstream
defined for the current branch, refused to run until
merge.defaultToUpstream is set to true.  Flip the default of that
configuration variable to true.
@@ -87,22 +87,20 @@ UI,