[PATCH] Documentation: fix and clarify grammar in git-merge docs.

[PATCH] Documentation: fix and clarify grammar in git-merge docs.

[dave]

From: Dave Peticolas <dave@krondo.com>


Signed-off-by: Dave Peticolas <dave@krondo.com>
---
 Documentation/git-merge.txt |   25 ++++++++++++-------------
 1 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index ed3a924..abf63fe 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -74,19 +74,18 @@ it happens.  In other words, `git-diff --cached HEAD` must
 report no changes.
 
 [NOTE]
-This is a bit of lie.  In certain special cases, your index are
-allowed to be different from the tree of `HEAD` commit.  The most
-notable case is when your `HEAD` commit is already ahead of what
-is being merged, in which case your index can have arbitrary
-difference from your `HEAD` commit.  Otherwise, your index entries
-are allowed have differences from your `HEAD` commit that match
-the result of trivial merge (e.g. you received the same patch
-from external source to produce the same result as what you are
-merging).  For example, if a path did not exist in the common
-ancestor and your head commit but exists in the tree you are
-merging into your repository, and if you already happen to have
-that path exactly in your index, the merge does not have to
-fail.
+This is a bit of a lie.  In certain special cases, your index is
+allowed to be different from the tree of the `HEAD` commit.  The
+most notable case is when your `HEAD` commit is already ahead of
+what is being merged, in which case your index can have arbitrary
+differences from your `HEAD` commit.  Also, your index entries may
+have differences from your `HEAD` commit that match the result of
+a trivial merge (e.g., you received the same patch from an external
+source to produce the same result as what you are merging).  For example,
+if a path did not exist in the common ancestor and your head commit
+but exists in the tree you are merging into your repository, and if
+you already happen to have that path exactly in your index, the merge
+does not have to fail.
 
 Otherwise, merge will refuse to do any harm to your repository
 (that is, it may fetch the objects from remote, and it may even
-- 
1.5.3.8

Re: [PATCH] Documentation: fix and clarify grammar in git-merge docs.

[Junio C Hamano]

dave@krondo.com writes:

> From: Dave Peticolas <dave@krondo.com>
>
>
> Signed-off-by: Dave Peticolas <dave@krondo.com>
> ---
>  Documentation/git-merge.txt |   25 ++++++++++++-------------
>  1 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> index ed3a924..abf63fe 100644
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -74,19 +74,18 @@ it happens.  In other words, `git-diff --cached HEAD` must
>  report no changes.
>  
>  [NOTE]
> -This is a bit of lie.  In certain special cases, your index are
> -allowed to be different from the tree of `HEAD` commit.  The most
> -notable case is when your `HEAD` commit is already ahead of what
> -is being merged, in which case your index can have arbitrary
> -difference from your `HEAD` commit.  Otherwise, your index entries
> -are allowed have differences from your `HEAD` commit that match
> -the result of trivial merge (e.g. you received the same patch
> -from external source to produce the same result as what you are
> -merging).  For example, if a path did not exist in the common
> -ancestor and your head commit but exists in the tree you are
> -merging into your repository, and if you already happen to have
> -that path exactly in your index, the merge does not have to
> -fail.
> +This is a bit of a lie.  In certain special cases, your index is
> +allowed to be different from the tree of the `HEAD` commit.  The
> +most notable case is when your `HEAD` commit is already ahead of
> +what is being merged, in which case your index can have arbitrary
> +differences from your `HEAD` commit.  Also, your index entries may
> +have differences from your `HEAD` commit that match the result of
> +a trivial merge (e.g., you received the same patch from an external
> +source to produce the same result as what you are merging).  For example,
> +if a path did not exist in the common ancestor and your head commit
> +but exists in the tree you are merging into your repository, and if
> +you already happen to have that path exactly in your index, the merge
> +does not have to fail.

While checking and fixing the grammatical errors is very much
appreciated, line re-wrapping is not.  It makes it unnecessarily
cumbersome to see what got really changed.

Thanks anyway.  The changes look good.

[PATCH] Documentation: fix and clarify grammar in git-merge docs.

[dave]

From: Dave Peticolas <dave@krondo.com>

---
 Documentation/git-merge.txt |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index ed3a924..4494595 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -74,14 +74,14 @@ it happens.  In other words, `git-diff --cached HEAD` must
 report no changes.
 
 [NOTE]
-This is a bit of lie.  In certain special cases, your index are
-allowed to be different from the tree of `HEAD` commit.  The most
+This is a bit of a lie.  In certain special cases, your index is
+allowed to be different from the tree of the `HEAD` commit.  The most
 notable case is when your `HEAD` commit is already ahead of what
 is being merged, in which case your index can have arbitrary
-difference from your `HEAD` commit.  Otherwise, your index entries
-are allowed have differences from your `HEAD` commit that match
-the result of trivial merge (e.g. you received the same patch
-from external source to produce the same result as what you are
+differences from your `HEAD` commit.  Also, your index entries
+may have differences from your `HEAD` commit that match
+the result of a trivial merge (e.g., you received the same patch
+from an external source to produce the same result as what you are
 merging).  For example, if a path did not exist in the common
 ancestor and your head commit but exists in the tree you are
 merging into your repository, and if you already happen to have
-- 
1.5.3.8