patchwording fixes in the user manual and glossary

> Some minor wording fixes in the user manual and glossary.
> 
> Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
> ---
>  Documentation/glossary-content.txt | 2 +-
>  Documentation/user-manual.txt      | 8 ++++----
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
> index be0858c..4e0b971 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -1,7 +1,7 @@
>  [[def_alternate_object_database]]alternate object database::
>  	Via the alternates mechanism, a <<def_repository,repository>>
>  	can inherit part of its <<def_object_database,object database>>
> -	from another object database, which is called "alternate".
> +	from another object database, which is called an "alternate".
>  
>  [[def_bare_repository]]bare repository::
>  	A bare repository is normally an appropriately
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index d33f884..efb3c97 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -416,7 +416,7 @@ REVISIONS" section of linkgit:gitrevisions[7].
>  Updating a repository with git fetch
>  ------------------------------------
>  
> -Eventually the developer cloned from will do additional work in her
> +Eventually the developer will do additional work in her cloned
>  repository, creating new commits and advancing the branches to point
>  at the new commits.

>  
> @@ -1811,8 +1811,8 @@ manner.
>  You can then import these into your mail client and send them by
>  hand.  However, if you have a lot to send at once, you may prefer to
>  use the linkgit:git-send-email[1] script to automate the process.
> -Consult the mailing list for your project first to determine how they
> -prefer such patches be handled.
> +Consult the mailing list for your project first to determine
> +their requirements for submitting patches.
>  
>  [[importing-patches]]
>  Importing patches to a project
> @@ -2255,7 +2255,7 @@ $ git checkout test && git merge speed-up-spinlocks
>  It is unlikely that you would have any conflicts here ... but you might if you
>  spent a while on this step and had also pulled new versions from upstream.
>  
> -Some time later when enough time has passed and testing done, you can pull the
> +Sometime later when enough time has passed and testing done, you can pull the
>  same branch into the `release` tree ready to go upstream.  This is where you
>  see the value of keeping each patch (or patch series) in its own branch.  It
>  means that the patches can be moved into the `release` tree in any order.
> 

> >  
> > -Eventually the developer cloned from will do additional work in her
> > +Eventually the developer will do additional work in her cloned
> >  repository, creating new commits and advancing the branches to point
> >  at the new commits.
> 
> I agree that the original wording isn't clear but I'm not sure the new
> wording is any clearer. The paragraph is trying to explain how to fetch
> upstream changes when they happen. My initial thought was to say
> "Eventually the developer will do additional work in the upstream
> repository" but perhaps it is to early to start throwing around terms
> like upstream. Perhaps just saying "her repository" would be clearest.
> 

> On Sun, May 25, 2014 at 07:56:41PM +1200, Chris Packham wrote:
>> On 25/05/14 15:50, Jeremiah Mahler wrote:
>>> Some minor wording fixes in the user manual and glossary.
> ...
>>>  
>>> -Eventually the developer cloned from will do additional work in her
>>> +Eventually the developer will do additional work in her cloned
>>>  repository, creating new commits and advancing the branches to point
>>>  at the new commits.
>>
>> I agree that the original wording isn't clear but I'm not sure the new
>> wording is any clearer. The paragraph is trying to explain how to fetch
>> upstream changes when they happen. My initial thought was to say
>> "Eventually the developer will do additional work in the upstream
>> repository" but perhaps it is to early to start throwing around terms
>> like upstream. Perhaps just saying "her repository" would be clearest.
>>
> 
> The "developer cloned from will do" didn't sound right to me.
> But it sounds like my interpretation is not what you were trying to
> convey.  I do like the "upstream" term, it helps describe the
> local/remote aspect.
> 
> How about this:
> 
>   Eventually the upstream developer will do additional work in their
>   repository.  Creating new commits and advancing the branches to point
>   at the new commits.

>> How about this:
>>
>>    Eventually the upstream developer will do additional work in their
>>    repository.  Creating new commits and advancing the branches to point
>>    at the new commits.
>