git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 16, 2008, 19:07 UTC
Message-ID
<7vd4s1r3m6.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<1200460565-16797-1-git-send-email-dave@krondo.com>
dave@krondo.com writes:
Show 41 quoted lines
> 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.
Previous: dave@krondo.com
Message 2 of 2 in “Documentation: fix and clarify grammar in git-merge docs.”
  1. Documentation: fix and clarify grammar in git-merge docs.dave@krondo.com, Jan 16, 2008
  2. Junio C HamanoJan 16, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.