{"thread":{"id":"36748","subject":"[PATCH] wording fixes in the user manual and glossary","startedAt":"2014-05-25T03:50:41Z","lastAt":"2014-05-26T08:11:43Z","messageCount":5,"participants":["Jeremiah Mahler","Chris Packham","Ben Aveling"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"242644","messageId":"1400989841-2845-1-git-send-email-jmmahler@gmail.com","threadId":"36748","inReplyTo":null,"subject":"[PATCH] wording fixes in the user manual and glossary","fromName":"Jeremiah Mahler","fromEmail":"jmmahler@gmail.com","sentAt":"2014-05-25T03:50:41Z","receivedAt":"2014-05-25T03:50:41Z","isPatch":true,"sender":{"key":"jmmahler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/154028?v=4"},"body":"Some minor wording fixes in the user manual and glossary.\n\nSigned-off-by: Jeremiah Mahler \n---\n Documentation/glossary-content.txt | 2 +-\n Documentation/user-manual.txt | 8 ++++----\n 2 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt\nindex be0858c..4e0b971 100644\n--- a/Documentation/glossary-content.txt\n+++ b/Documentation/glossary-content.txt\n@@ -1,7 +1,7 @@\n [[def_alternate_object_database]]alternate object database::\n \tVia the alternates mechanism, a <>\n \tcan inherit part of its <>\n-\tfrom another object database, which is called \"alternate\".\n+\tfrom another object database, which is called an \"alternate\".\n \n [[def_bare_repository]]bare repository::\n \tA bare repository is normally an appropriately\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex d33f884..efb3c97 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -416,7 +416,7 @@ REVISIONS\" section of linkgit:gitrevisions[7].\n Updating a repository with git fetch\n ------------------------------------\n \n-Eventually the developer cloned from will do additional work in her\n+Eventually the developer will do additional work in her cloned\n repository, creating new commits and advancing the branches to point\n at the new commits.\n \n@@ -1811,8 +1811,8 @@ manner.\n You can then import these into your mail client and send them by\n hand. However, if you have a lot to send at once, you may prefer to\n use the linkgit:git-send-email[1] script to automate the process.\n-Consult the mailing list for your project first to determine how they\n-prefer such patches be handled.\n+Consult the mailing list for your project first to determine\n+their requirements for submitting patches.\n \n [[importing-patches]]\n Importing patches to a project\n@@ -2255,7 +2255,7 @@ $ git checkout test && git merge speed-up-spinlocks\n It is unlikely that you would have any conflicts here ... but you might if you\n spent a while on this step and had also pulled new versions from upstream.\n \n-Some time later when enough time has passed and testing done, you can pull the\n+Sometime later when enough time has passed and testing done, you can pull the\n same branch into the `release` tree ready to go upstream. This is where you\n see the value of keeping each patch (or patch series) in its own branch. It\n means that the patches can be moved into the `release` tree in any order.\n-- \n2.0.0.rc4.479.gd6c9c28\n"},{"id":"242660","messageId":"5381A239.2060809@gmail.com","threadId":"36748","inReplyTo":"1400989841-2845-1-git-send-email-jmmahler@gmail.com","subject":"Re: [PATCH] wording fixes in the user manual and glossary","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2014-05-25T07:56:41Z","receivedAt":"2014-05-25T07:56:41Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 25/05/14 15:50, Jeremiah Mahler wrote:\n> Some minor wording fixes in the user manual and glossary.\n> \n> Signed-off-by: Jeremiah Mahler \n> ---\n> Documentation/glossary-content.txt | 2 +-\n> Documentation/user-manual.txt | 8 ++++----\n> 2 files changed, 5 insertions(+), 5 deletions(-)\n> \n> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt\n> index be0858c..4e0b971 100644\n> --- a/Documentation/glossary-content.txt\n> +++ b/Documentation/glossary-content.txt\n> @@ -1,7 +1,7 @@\n> [[def_alternate_object_database]]alternate object database::\n> \tVia the alternates mechanism, a <>\n> \tcan inherit part of its <>\n> -\tfrom another object database, which is called \"alternate\".\n> +\tfrom another object database, which is called an \"alternate\".\n> \n> [[def_bare_repository]]bare repository::\n> \tA bare repository is normally an appropriately\n> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> index d33f884..efb3c97 100644\n> --- a/Documentation/user-manual.txt\n> +++ b/Documentation/user-manual.txt\n> @@ -416,7 +416,7 @@ REVISIONS\" section of linkgit:gitrevisions[7].\n> Updating a repository with git fetch\n> ------------------------------------\n> \n> -Eventually the developer cloned from will do additional work in her\n> +Eventually the developer will do additional work in her cloned\n> repository, creating new commits and advancing the branches to point\n> at the new commits.\n\nI agree that the original wording isn't clear but I'm not sure the new\nwording is any clearer. The paragraph is trying to explain how to fetch\nupstream changes when they happen. My initial thought was to say\n\"Eventually the developer will do additional work in the upstream\nrepository\" but perhaps it is to early to start throwing around terms\nlike upstream. Perhaps just saying \"her repository\" would be clearest.\n\n> \n> @@ -1811,8 +1811,8 @@ manner.\n> You can then import these into your mail client and send them by\n> hand. However, if you have a lot to send at once, you may prefer to\n> use the linkgit:git-send-email[1] script to automate the process.\n> -Consult the mailing list for your project first to determine how they\n> -prefer such patches be handled.\n> +Consult the mailing list for your project first to determine\n> +their requirements for submitting patches.\n> \n> [[importing-patches]]\n> Importing patches to a project\n> @@ -2255,7 +2255,7 @@ $ git checkout test && git merge speed-up-spinlocks\n> It is unlikely that you would have any conflicts here ... but you might if you\n> spent a while on this step and had also pulled new versions from upstream.\n> \n> -Some time later when enough time has passed and testing done, you can pull the\n> +Sometime later when enough time has passed and testing done, you can pull the\n> same branch into the `release` tree ready to go upstream. This is where you\n> see the value of keeping each patch (or patch series) in its own branch. It\n> means that the patches can be moved into the `release` tree in any order.\n> \n"},{"id":"242661","messageId":"20140525083720.GA28739@hudson.localdomain","threadId":"36748","inReplyTo":"5381A239.2060809@gmail.com","subject":"Re: [PATCH] wording fixes in the user manual and glossary","fromName":"Jeremiah Mahler","fromEmail":"jmmahler@gmail.com","sentAt":"2014-05-25T08:37:20Z","receivedAt":"2014-05-25T08:37:20Z","isPatch":true,"sender":{"key":"jmmahler@gmail.com","avatar":"https://avatars.githubusercontent.com/u/154028?v=4"},"body":"On Sun, May 25, 2014 at 07:56:41PM +1200, Chris Packham wrote:\n> On 25/05/14 15:50, Jeremiah Mahler wrote:\n> > Some minor wording fixes in the user manual and glossary.\n...\n> > \n> > -Eventually the developer cloned from will do additional work in her\n> > +Eventually the developer will do additional work in her cloned\n> > repository, creating new commits and advancing the branches to point\n> > at the new commits.\n> \n> I agree that the original wording isn't clear but I'm not sure the new\n> wording is any clearer. The paragraph is trying to explain how to fetch\n> upstream changes when they happen. My initial thought was to say\n> \"Eventually the developer will do additional work in the upstream\n> repository\" but perhaps it is to early to start throwing around terms\n> like upstream. Perhaps just saying \"her repository\" would be clearest.\n> \n\nThe \"developer cloned from will do\" didn't sound right to me.\nBut it sounds like my interpretation is not what you were trying to\nconvey. I do like the \"upstream\" term, it helps describe the\nlocal/remote aspect.\n\nHow about this:\n\n Eventually the upstream developer will do additional work in their\n repository. Creating new commits and advancing the branches to point\n at the new commits.\n\nThen in the next paragraph it will discuss how to use `git fetch`\nto get these remote changes in to the local repository.\n\n-- \nJeremiah Mahler\njmmahler@gmail.com\nhttp://github.com/jmahler\n"},{"id":"242666","messageId":"5382F237.8070909@gmail.com","threadId":"36748","inReplyTo":"20140525083720.GA28739@hudson.localdomain","subject":"Re: [PATCH] wording fixes in the user manual and glossary","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2014-05-26T07:50:15Z","receivedAt":"2014-05-26T07:50:15Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 25/05/14 20:37, Jeremiah Mahler wrote:\n> On Sun, May 25, 2014 at 07:56:41PM +1200, Chris Packham wrote:\n>> On 25/05/14 15:50, Jeremiah Mahler wrote:\n>>> Some minor wording fixes in the user manual and glossary.\n> ...\n>>> \n>>> -Eventually the developer cloned from will do additional work in her\n>>> +Eventually the developer will do additional work in her cloned\n>>> repository, creating new commits and advancing the branches to point\n>>> at the new commits.\n>>\n>> I agree that the original wording isn't clear but I'm not sure the new\n>> wording is any clearer. The paragraph is trying to explain how to fetch\n>> upstream changes when they happen. My initial thought was to say\n>> \"Eventually the developer will do additional work in the upstream\n>> repository\" but perhaps it is to early to start throwing around terms\n>> like upstream. Perhaps just saying \"her repository\" would be clearest.\n>>\n> \n> The \"developer cloned from will do\" didn't sound right to me.\n> But it sounds like my interpretation is not what you were trying to\n> convey. I do like the \"upstream\" term, it helps describe the\n> local/remote aspect.\n> \n> How about this:\n> \n> Eventually the upstream developer will do additional work in their\n> repository. Creating new commits and advancing the branches to point\n> at the new commits.\n\nSounds good to me.\n\n> \n> Then in the next paragraph it will discuss how to use `git fetch`\n> to get these remote changes in to the local repository.\n> \n"},{"id":"242667","messageId":"5382F73F.2010704@optusnet.com.au","threadId":"36748","inReplyTo":"5382F237.8070909@gmail.com","subject":"Re: [PATCH] wording fixes in the user manual and glossary","fromName":"Ben Aveling","fromEmail":"bena.001@optusnet.com.au","sentAt":"2014-05-26T08:11:43Z","receivedAt":"2014-05-26T08:11:43Z","isPatch":true,"sender":{"key":"bena.001@optusnet.com.au","avatar":null},"body":"On 25/05/14 20:37, Jeremiah Mahler wrote:\n>> How about this:\n>>\n>> Eventually the upstream developer will do additional work in their\n>> repository. Creating new commits and advancing the branches to point\n>> at the new commits.\n>\n\nThe second sentence needs a verb. Maybe something along the lines of \n\"When they ${do_X}, ${Y} will happen\" ?\n\nRegards, Ben\n"}]}