Re: [PATCH] Fix grammar in the 1.8.3 release notes.

4 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] Fix grammar in the 1.8.3 release notes.

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:04

Marc Branchaud [off-list ref] writes:
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
Thanks.
  * "git bundle" did not like a bundle created using a commit without
-   any message as its one of the prerequistes.
+   any message, as it is one of the prerequistes.
This is actually saying a different thing.  

When you create a bundle, you can say "you can only unbundle this in
a repository that has commit X", with "git bundle create $name ^X Y
Z".  Such a commit X is called the bundle's prerequisite.  You can
have more than one prerequisite, e.g. "... ^X ^W Y Z".

But if you create a bundle by using a commit that does not have any
message as X (i.e. the bundle's prerequisite), the "git bundle" did
not like to read the resulting bundle output.

So <a commit <without any message> as its (bundle's) one of the
prerequisites> is what the original wanted to say.  The rewrite
makes it read like "For a commit, having a message is a requirement
to be used in a bundle", at least to me.
quoted hunk
  * "index-pack --fix-thin" used an uninitialized value to compute
-   delta depths of objects it appends to the resulting pack.
+   the delta depths of objects it appends to the resulting pack.
 
- * "index-pack --verify-stat" used a few counters outside protection
-   of mutex, possibly showing incorrect numbers.
+ * "index-pack --verify-stat" used a few counters outside the protection
+   of a mutex, possibly showing incorrect numbers.
 
  * The code to keep track of what directory names are known to Git on
-   platforms with case insensitive filesystems can get confused upon a
-   hash collision between these pathnames and looped forever.
+   platforms with case insensitive filesystems could get confused upon a
+   hash collision between these pathnames and would loop forever.
 
- * Annotated tags outside refs/tags/ hierarchy were not advertised
-   correctly to the ls-remote and fetch with recent version of Git.
+ * Annotated tags outside the refs/tags/ hierarchy were not advertised
+   correctly to ls-remote and fetch with recent versions of Git.
 
- * Recent optimization broke shallow clones.
+ * Recent optimizations broke shallow clones.
 
  * "git cmd -- ':(top'" was not diagnosed as an invalid syntax, and
    instead the parser kept reading beyond the end of the string.
 
  * "git tag -f <tag>" always said "Updated tag '<tag>'" even when
-   creating a new tag (i.e. not overwriting nor updating).
+   creating a new tag (i.e. neither overwriting nor updating).
 
  * "git p4" did not behave well when the path to the root of the P4
    client was not its real path.
    (merge bbd8486 pw/p4-symlinked-root later to maint).
 
- * "git archive" reports a failure when asked to create an archive out
-   of an empty tree.  It would be more intuitive to give an empty
+ * "git archive" reported a failure when asked to create an archive out
+   of an empty tree.  It is more intuitive to give an empty
    archive back in such a case.
 
- * When "format-patch" quoted a non-ascii strings on the header files,
+ * When "format-patch" quoted a non-ascii string in header files,
    it incorrectly applied rfc2047 and chopped a single character in
-   the middle of it.
+   the middle of the string.
 
  * An aliased command spawned from a bare repository that does not say
-   it is bare with "core.bare = yes" is treated as non-bare by mistake.
+   it is bare with "core.bare = yes" was treated as non-bare by mistake.
 
- * In "git reflog expire", REACHABLE bit was not cleared from the
+ * In "git reflog expire", the REACHABLE bit was not cleared from the
    correct objects.
 
  * The logic used by "git diff -M --stat" to shorten the names of
@@ -347,9 +346,9 @@ details).
    common prefix and suffix between the two filenames overlapped.
 
  * The "--match=<pattern>" option of "git describe", when used with
-   "--all" to allow refs that are not annotated tags to be used as a
+   "--all" to allow refs that are not annotated tags to be a
    base of description, did not restrict the output from the command
-   to those that match the given pattern.
+   to those refs that match the given pattern.
 
  * Clarify in the documentation "what" gets pushed to "where" when the
    command line to "git push" does not say these explicitly.
@@ -357,7 +356,7 @@ details).
  * The "--color=<when>" argument to the commands in the diff family
    was described poorly.
 
- * The arguments given to pre-rebase hook were not documented.
+ * The arguments given to the pre-rebase hook were not documented.
 
  * The v4 index format was not documented.
 
@@ -375,7 +374,7 @@ details).
 
  * In the v1.8.0 era, we changed symbols that do not have to be global
    to file scope static, but a few functions in graph.c were used by
-   CGit from sideways bypassing the entry points of the API the
+   CGit sideways, bypassing the entry points of the API the
    in-tree users use.
 
  * "git update-index -h" did not do the usual "-h(elp)" thing.
@@ -388,30 +387,30 @@ details).
    $msg already ended with one.
 
  * The SSL peer verification done by "git imap-send" did not ask for
-   Server Name Indication (RFC 4366), failing to connect SSL/TLS
+   Server Name Indication (RFC 4366), failing to connect to SSL/TLS
    sites that serve multiple hostnames on a single IP.
 
  * perl/Git.pm::cat_blob slurped everything in core only to write it
    out to a file descriptor, which was not a very smart thing to do.
 
  * "git branch" did not bother to check nonsense command line
-   parameters and issue errors in many cases.
+   parameters.  It now issues errors in many cases.
 
- * Verification of signed tags were not done correctly when not in C
+ * Verification of signed tags was not done correctly when not in C
    or en/US locale.
 
  * Some platforms and users spell UTF-8 differently; retry with the
    most official "UTF-8" when the system does not understand the
-   user-supplied encoding name that are the common alternative
-   spellings of UTF-8.
+   user-supplied encoding name that is a common alternative
+   spelling of UTF-8.
 
- * When export-subst is used, "zip" output recorded incorrect
+ * When export-subst is used, "zip" output recorded an incorrect
    size of the file.
 
  * "git am $maildir/" applied messages in an unexpected order; sort
    filenames read from the maildir/ in a way that is more likely to
-   sort messages in the order the writing MUA meant to, by sorting
-   numeric segment in numeric order and non-numeric segment in
+   sort the messages in the order the writing MUA meant to, by sorting
+   numeric segments in numeric order and non-numeric segments in
    alphabetical order.
 
  * "git submodule update", when recursed into sub-submodules, did not

Re: [PATCH] Fix grammar in the 1.8.3 release notes.

From: Marc Branchaud <hidden>
Date: 2016-06-15 22:57:04

On 13-04-29 05:15 PM, Junio C Hamano wrote:
Marc Branchaud [off-list ref] writes:
quoted
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
Thanks.
quoted
  * "git bundle" did not like a bundle created using a commit without
-   any message as its one of the prerequistes.
+   any message, as it is one of the prerequistes.
This is actually saying a different thing.  

When you create a bundle, you can say "you can only unbundle this in
a repository that has commit X", with "git bundle create $name ^X Y
Z".  Such a commit X is called the bundle's prerequisite.  You can
have more than one prerequisite, e.g. "... ^X ^W Y Z".

But if you create a bundle by using a commit that does not have any
message as X (i.e. the bundle's prerequisite), the "git bundle" did
not like to read the resulting bundle output.

So <a commit <without any message> as its (bundle's) one of the
prerequisites> is what the original wanted to say.  The rewrite
makes it read like "For a commit, having a message is a requirement
to be used in a bundle", at least to me.
Thanks, I did get that wrong.

CC'ing Lukas, who wrote the relevant commit (5446e33f35).

How about:

* "git bundle" can create a bundle that has a commit without a message as
  a prerequisite, but it could not work with such a bundle.

		M.

Re: [PATCH] Fix grammar in the 1.8.3 release notes.

From: Lukas Fleischer <hidden>
Date: 2016-06-15 22:57:05

On Tue, Apr 30, 2013 at 10:28:21AM -0400, Marc Branchaud wrote:
On 13-04-29 05:15 PM, Junio C Hamano wrote:
quoted
Marc Branchaud [off-list ref] writes:
quoted
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
Thanks.
quoted
  * "git bundle" did not like a bundle created using a commit without
-   any message as its one of the prerequistes.
+   any message, as it is one of the prerequistes.
This is actually saying a different thing.  

When you create a bundle, you can say "you can only unbundle this in
a repository that has commit X", with "git bundle create $name ^X Y
Z".  Such a commit X is called the bundle's prerequisite.  You can
have more than one prerequisite, e.g. "... ^X ^W Y Z".

But if you create a bundle by using a commit that does not have any
message as X (i.e. the bundle's prerequisite), the "git bundle" did
not like to read the resulting bundle output.

So <a commit <without any message> as its (bundle's) one of the
prerequisites> is what the original wanted to say.  The rewrite
makes it read like "For a commit, having a message is a requirement
to be used in a bundle", at least to me.
Thanks, I did get that wrong.

CC'ing Lukas, who wrote the relevant commit (5446e33f35).

How about:

* "git bundle" can create a bundle that has a commit without a message as
  a prerequisite, but it could not work with such a bundle.
Looks fine to me.

Junio's version with the last part changed to "as one of its
prerequisites" sounds also good to me (in both cases, however, note the
missing "i" in "prerequisites").

A third suggestion:

    "git bundle" erroneously bailed out when parsing a valid bundle
    containing a prerequisite commit without a commit message.
		M.

Re: [PATCH] Fix grammar in the 1.8.3 release notes.

From: Marc Branchaud <hidden>
Date: 2016-06-15 22:57:06

On 13-05-01 04:24 AM, Lukas Fleischer wrote:
On Tue, Apr 30, 2013 at 10:28:21AM -0400, Marc Branchaud wrote:
quoted
On 13-04-29 05:15 PM, Junio C Hamano wrote:
quoted
Marc Branchaud [off-list ref] writes:
quoted
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
Thanks.
quoted
  * "git bundle" did not like a bundle created using a commit without
-   any message as its one of the prerequistes.
+   any message, as it is one of the prerequistes.
This is actually saying a different thing.  

When you create a bundle, you can say "you can only unbundle this in
a repository that has commit X", with "git bundle create $name ^X Y
Z".  Such a commit X is called the bundle's prerequisite.  You can
have more than one prerequisite, e.g. "... ^X ^W Y Z".

But if you create a bundle by using a commit that does not have any
message as X (i.e. the bundle's prerequisite), the "git bundle" did
not like to read the resulting bundle output.

So <a commit <without any message> as its (bundle's) one of the
prerequisites> is what the original wanted to say.  The rewrite
makes it read like "For a commit, having a message is a requirement
to be used in a bundle", at least to me.
Thanks, I did get that wrong.

CC'ing Lukas, who wrote the relevant commit (5446e33f35).

How about:

* "git bundle" can create a bundle that has a commit without a message as
  a prerequisite, but it could not work with such a bundle.
Looks fine to me.

Junio's version with the last part changed to "as one of its
prerequisites" sounds also good to me (in both cases, however, note the
missing "i" in "prerequisites").

A third suggestion:

    "git bundle" erroneously bailed out when parsing a valid bundle
    containing a prerequisite commit without a commit message.
I like that best.

		M.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help