patchFix incorrect wording in git-merge.txt.

> A merge is not necessarily with a remote branch, it can be with any
> commit object.
> ---
>  Documentation/git-merge.txt |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> index 0c9ad7f..193c9c0 100644
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -68,7 +68,8 @@ HOW MERGE WORKS
>  ---------------
>  
>  A merge is always between the current `HEAD` and one or more
> -remote branch heads, and the index file must exactly match the
> +commit objects (usually, branch head or tag), and the index file must
> +exactly match the
>  tree of `HEAD` commit (i.e. the contents of the last commit) when
>  it happens.  In other words, `git-diff --cached HEAD` must
>  report no changes.

> Nicolas Pitre <nico@cam.org> writes:
> 
> > You don't really merge a commit _object_.
> > You merge with one or more other commits, tipycally identified by a 
> > branch name or a tag.
> 
> Strictly speaking, you can merge any commit, not necessarily a branch
> or a tag. That can be "git merge 66f0a4d" or whatever. Admitedly, the
> common case is to merge a tag or a branch (which is why I keep it in
> parentheses).

>> Now, I don't understand the distinction you seem to be making between
>> "commit" and "commit object".
>
> Objects are what the low level storage is made of.  Conceptually, The 
> merge operation doesn't work at the object level, but rather at the 
> history graph level.

> Nicolas Pitre <nico@cam.org> writes:
> 
> >> Now, I don't understand the distinction you seem to be making between
> >> "commit" and "commit object".
> >
> > Objects are what the low level storage is made of.  Conceptually, The 
> > merge operation doesn't work at the object level, but rather at the 
> > history graph level.
> 
> I still don't get the distinction. What is the "graph" if not a set of
> objects pointing to each other?
> 
> If you don't want to talk about commit object, then you should fix
> also user-manual.txt (for example, it states that a merge "create a
> commit object in the history").
> 
> Well, that said, the same sentence as the one I propose without
> "object" is fine to me, but I just don't understand the difference.

> On Mon, 3 Mar 2008, Matthieu Moy wrote:
> 
>> Nicolas Pitre <nico@cam.org> writes:
>>
>>> You don't really merge a commit _object_.
>>> You merge with one or more other commits, tipycally identified by a 
>>> branch name or a tag.
>> Strictly speaking, you can merge any commit, not necessarily a branch
>> or a tag. That can be "git merge 66f0a4d" or whatever. Admitedly, the
>> common case is to merge a tag or a branch (which is why I keep it in
>> parentheses).
> 
> Yes, and I've been meaning the same all along.
> 
>> Now, I don't understand the distinction you seem to be making between
>> "commit" and "commit object".
> 
> Objects are what the low level storage is made of.  Conceptually, The 
> merge operation doesn't work at the object level, but rather at the 
> history graph level.  You don't merge objects, you merge history.
> I think it is unnecessary and probably best not to 
> mention the word "object" in this case.
> 
> The alternative is to provide more detailed explanation, such as:
> 
>    A merge is made by joining one or more history line to the current 
>    'HEAD' branch.  Those history lines are denoted by their terminating 
>    commit.  To identify them, the SHA1 name of the corresponding commit 
>    object is used, or more frequently the name of the branch or tag 
>    currently pointing at such commit objects.
>