{"thread":{"id":"6625","subject":"[PATCH] fix some doc typos and grammar","startedAt":"2007-02-02T06:25:30Z","lastAt":"2007-02-02T11:43:29Z","messageCount":6,"participants":["Mike Coleman","Junio C Hamano","Andy Parkins","Jakub Narebski","Uwe Kleine-König"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"33343","messageId":"3c6c07c20702012225v19b7aa66vc98a028f700914db@mail.gmail.com","threadId":"6625","inReplyTo":null,"subject":"[PATCH] fix some doc typos and grammar","fromName":"Mike Coleman","fromEmail":"tutufan@gmail.com","sentAt":"2007-02-02T06:25:30Z","receivedAt":"2007-02-02T06:25:30Z","isPatch":true,"sender":{"key":"tutufan@gmail.com","avatar":null},"body":"[This is my first patch, which I'm trying via cut-and-paste into\ngmail, which I realize sucks. Any ideas for a better way? Is anyone\nsending patches via gmail+pop? I gave up my previous shell/email\nprovider because they just weren't keeping the spam down. Any\nsuggestions for something that works? --Mike]\n\nsuggest user manual mention .gitignore\n\nSigned-off-by: Michael Coleman \n---\n Documentation/core-tutorial.txt | 6 +++---\n Documentation/user-manual.txt | 8 +++++---\n 2 files changed, 8 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt\nindex 86a9c75..1cd834b 100644\n--- a/Documentation/core-tutorial.txt\n+++ b/Documentation/core-tutorial.txt\n@@ -624,7 +624,7 @@ name for the state at that point.\n Copying repositories\n --------------------\n\n-git repositories are normally totally self-sufficient and relocatable\n+git repositories are normally totally self-sufficient and relocatable.\n Unlike CVS, for example, there is no separate notion of\n \"repository\" and \"working tree\". A git repository normally *is* the\n working tree, with the local git information hidden in the `.git`\n@@ -1118,7 +1118,7 @@ You could do without using any branches at all, by\n keeping as many local repositories as you would like to have\n branches, and merging between them with `git pull`, just like\n you merge between branches. The advantage of this approach is\n-that it lets you keep set of files for each `branch` checked\n+that it lets you keep a set of files for each `branch` checked\n out and you may find it easier to switch back and forth if you\n juggle multiple lines of development simultaneously. Of\n course, you will pay the price of more disk usage to hold\n@@ -1300,7 +1300,7 @@ differences since stage 2 (i.e. your version).\n Publishing your work\n --------------------\n\n-So we can use somebody else's work from a remote repository; but\n+So, we can use somebody else's work from a remote repository, but\n how can *you* prepare a repository to let other people pull from\n it?\n\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex b6916d1..6576625 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -398,7 +398,7 @@ branch name, but this longer name can also be useful. Most\n importantly, it is a globally unique name for this commit: so if you\n tell somebody else the object name (for example in email), then you are\n guaranteed that name will refer to the same commit in their repository\n-that you it does in yours (assuming their repository has that commit at\n+that it does in yours (assuming their repository has that commit at\n all).\n\n Understanding history: commits, parents, and reachability\n@@ -617,7 +617,7 @@ the relationships between these snapshots.\n Git provides extremely flexible and fast tools for exploring the\n history of a project.\n\n-We start with one specialized tool which is useful for finding the\n+We start with one specialized tool that is useful for finding the\n commit that introduced a bug into a project.\n\n How to use bisect to find a regression\n@@ -1492,7 +1492,7 @@ dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5\n ...\n -------------------------------------------------\n\n-and watch for output that mentions \"dangling commits\". You can examine\n+You can examine\n one of those dangling commits with, for example,\n\n ------------------------------------------------\n@@ -2923,6 +2923,8 @@ Think about how to create a clear chapter\ndependency graph that will\n allow people to get to important topics without necessarily reading\n everything in between.\n\n+Say something about .gitignore.\n+\n Scan Documentation/ for other stuff left out; in particular:\n \thowto's\n \tsome of technical/?\n-- \n1.5.0.rc3\n"},{"id":"33344","messageId":"7vmz3xjbxv.fsf@assigned-by-dhcp.cox.net","threadId":"6625","inReplyTo":"3c6c07c20702012225v19b7aa66vc98a028f700914db@mail.gmail.com","subject":"Re: [PATCH] fix some doc typos and grammar","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-02T06:44:28Z","receivedAt":"2007-02-02T06:44:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Mike Coleman\" writes:\n\n> [This is my first patch, which I'm trying via cut-and-paste into\n> gmail, which I realize sucks. Any ideas for a better way? Is anyone\n> sending patches via gmail+pop? I gave up my previous shell/email\n> provider because they just weren't keeping the spam down. Any\n> suggestions for something that works? --Mike]\n\nIt is usually nicer to put this \"cover letter\" material below\nthe three dashes after Signed-off-by line; not a huge deal,\nthough.\n\nI was surprised that, for a patch that came from cut & paste via\ngmail, your patch did not have too many whitespace breakages.\nThere was only one -- this hunk:\n\n> @@ -2923,6 +2923,8 @@ Think about how to create a clear chapter\n> dependency graph that will\n> allow people to get to important topics without necessarily reading\n> everything in between.\n>...\n\nand after hand-fixing that overflowed hunk header, everything\ncleanly applied.\n\nIt might help if you did not say:\n\n\tContent-Type: text/plain; charset=ISO-8859-1; format=flowed\n\nas \"format=flawed\" often seem to corrupt patches by wrapping\nlines. This might be fixable just by futzing with your MUA\nsetting, or maybe gmail sets it and outside of your control; I\ndo not know which, because I do not use gmail myself.\n\n> @@ -617,7 +617,7 @@ the relationships between these snapshots.\n> Git provides extremely flexible and fast tools for exploring the\n> history of a project.\n>\n> -We start with one specialized tool which is useful for finding the\n> +We start with one specialized tool that is useful for finding the\n> commit that introduced a bug into a project.\n>\n> How to use bisect to find a regression\n\nAh, \"which or that\", very funny. At work today I was working\nwith somebody you know (AB) on a document, and he was fixing my\nthat to which. Now you are fixing my which to that.\n\nAll the other hunks looked reasonable to me. Thanks, will\napply, and I'll let others to fight over which and that ;-).\n"},{"id":"33350","messageId":"3c6c07c20702012326h551b9f32gb3d8238361105741@mail.gmail.com","threadId":"6625","inReplyTo":"7vmz3xjbxv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fix some doc typos and grammar","fromName":"Mike Coleman","fromEmail":"tutufan@gmail.com","sentAt":"2007-02-02T07:26:25Z","receivedAt":"2007-02-02T07:26:25Z","isPatch":true,"sender":{"key":"tutufan@gmail.com","avatar":null},"body":"On 2/2/07, Junio C Hamano wrote:\n> It is usually nicer to put this \"cover letter\" material below\n> the three dashes after Signed-off-by line; not a huge deal,\n> though.\n\nI remembered that the three dashes mattered, but I couldn't remember\nif it was above or below.\n\nIt turns out that it's fairly easy to configure gmail to accept an\nSMTP connection. This recipe shows how to configure ssmtp, which is\njust a really dumb sender, to work with gmail:\n\n http://www.destr0yr.com/article.php/Gmail_and_sSMTP\n\nThis makes git-send-email work directly, and avoids the gmail web MUA.\n\n> Ah, \"which or that\", very funny. At work today I was working\n> with somebody you know (AB) on a document, and he was fixing my\n> that to which. Now you are fixing my which to that.\n\nAmusingly enough, it was PE who taught me the difference between\n'that' and 'which' in the first place. Tell AB that MC says \"Hi\".\n:-)\n\nMike\n"},{"id":"33363","messageId":"200702020949.09655.andyparkins@gmail.com","threadId":"6625","inReplyTo":"7vmz3xjbxv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] fix some doc typos and grammar","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-02T09:49:08Z","receivedAt":"2007-02-02T09:49:08Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 February 02 06:44, Junio C Hamano wrote:\n\n> Ah, \"which or that\", very funny. At work today I was working\n> with somebody you know (AB) on a document, and he was fixing my\n> that to which. Now you are fixing my which to that.\n\nIn case anyone is interested; a handy rule of thumb (i.e. it isn't always \ntrue, but will hold you in good stead) is that \"which\" should be preceded by \na comma and \"that\" should not. If you write a sentence that requires the \ncomma, then it's \"which\"; if it requires not having a comma, then \nit's \"that\".\n\ne.g. \n\n\"git is a version control system, which is a piece of software used for \ntracking changes to files over time\"\n\n\"git is a version control system that has a fanatical following of users who \nwill kill anyone who asks for rename support\"\n\nIn the first case the \"which\" describes what a version control system is. In \nthe second, the \"that\" describes what git is.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"33373","messageId":"epv761$gc1$1@sea.gmane.org","threadId":"6625","inReplyTo":"3c6c07c20702012326h551b9f32gb3d8238361105741@mail.gmail.com","subject":"Re: [PATCH] fix some doc typos and grammar","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-02T11:28:19Z","receivedAt":"2007-02-02T11:28:19Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Mike Coleman wrote:\n> On 2/2/07, Junio C Hamano wrote:\n\n>> It is usually nicer to put this \"cover letter\" material below\n>> the three dashes after Signed-off-by line; not a huge deal,\n>> though.\n> \n> I remembered that the three dashes mattered, but I couldn't remember\n> if it was above or below.\n> \n> It turns out that it's fairly easy to configure gmail to accept an\n> SMTP connection. This recipe shows how to configure ssmtp, which is\n> just a really dumb sender, to work with gmail:\n> \n> http://www.destr0yr.com/article.php/Gmail_and_sSMTP\n> \n> This makes git-send-email work directly, and avoids the gmail web MUA.\n\nIt is fairly easy to do the same with sendmail (which is default MTA\nfor many Linux distributions). I have googled the answer thanks to\nsome tips on #git channel. You have to change /etc/mail/sendmail.mc\n(or the file where SMART_HOST is commented out), add your credentials\nto /etc/mail/authinfo, then compile changes using \"make -C /etc/mail\"\n(all of it as root, I think).\n\nYour credential should have the form (in /etc/mail/authinfo)\n\n AuthInfo:smtp.gmail.com \"U:username@gmail.com\" \"P:password\" \"M:PLAIN\"\n AuthInfo: \"U:username@gmail.com\" \"P:password\" \"M:PLAIN\"\n\nYou can store password base64 encoded by using \"P=base64pass\" instead.\n/etc/mail/authinfo should be readable only by sendmail.\n\nBelow here are changes I have made in diff form. Most probably only\nthe first chunk is needed; correct me if I'm wrong, please\n\n--- /etc/mail/sendmail.mc.orig 2005-05-06 14:35:09.000000000 +0200\n+++ /etc/mail/sendmail.mc 2006-11-25 17:20:50.000000000 +0100\n@@ -19,7 +19,7 @@\n dnl # Uncomment and edit the following line if your outgoing mail needs to\n dnl # be sent out through an external mail server:\n dnl #\n-dnl define(`SMART_HOST',`smtp.your.provider')\n+define(`SMART_HOST',`[smtp.gmail.com]')\n dnl #\n define(`confDEF_USER_ID',``8:12'')dnl\n dnl define(`confAUTO_REBUILD')dnl\n@@ -37,7 +37,7 @@\n dnl # The following allows relaying if the user authenticates, and disallows\n dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links\n dnl #\n-dnl define(`confAUTH_OPTIONS', `A p')dnl\n+define(`confAUTH_OPTIONS', `A p')dnl\n dnl # \n dnl # PLAIN is the preferred plaintext authentication method and used by\n dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do\n@@ -45,8 +45,8 @@\n dnl # guaranteed secure.\n dnl # Please remember that saslauthd needs to be running for AUTH. \n dnl #\n-dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl\n-dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl\n+TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl\n+define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl\n dnl #\n dnl # Rudimentary information on creating certificates for sendmail TLS:\n dnl # cd /usr/share/ssl/certs; make sendmail.pem\n@@ -71,6 +71,7 @@\n dnl FEATURE(delay_checks)dnl\n FEATURE(`no_default_msa',`dnl')dnl\n FEATURE(`smrsh',`/usr/sbin/smrsh')dnl\n+FEATURE(`authinfo',`hash -o /etc/mail/authinfo.db')dnl\n FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl\n FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl\n FEATURE(redirect)dnl\n@@ -153,7 +154,7 @@\n dnl # The following example makes mail from this host and any additional\n dnl # specified domains appear to be sent from mydomain.com\n dnl #\n-dnl MASQUERADE_AS(`mydomain.com')dnl\n+MASQUERADE_AS(`gmail.com')dnl\n dnl #\n dnl # masquerade not just the headers, but the envelope as well\n dnl #\n\nPerhaps we should have put those on GitWiki page. Any volunteers?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33374","messageId":"20070202114329.GA5081@cepheus","threadId":"6625","inReplyTo":"epv761$gc1$1@sea.gmane.org","subject":"How to configure your MTA [Was: [PATCH] fix some doc typos and grammar]","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-02-02T11:43:29Z","receivedAt":"2007-02-02T11:43:29Z","isPatch":true,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nJakub Narebski wrote:\n> > This makes git-send-email work directly, and avoids the gmail web MUA.\n> \n> It is fairly easy to do the same with sendmail (which is default MTA\n> for many Linux distributions). I have googled the answer thanks to\n> some tips on #git channel. You have to change /etc/mail/sendmail.mc\n> (or the file where SMART_HOST is commented out), add your credentials\n> to /etc/mail/authinfo, then compile changes using \"make -C /etc/mail\"\n> (all of it as root, I think).\n> \n> Your credential should have the form (in /etc/mail/authinfo)\n> \n> AuthInfo:smtp.gmail.com \"U:username@gmail.com\" \"P:password\" \"M:PLAIN\"\n> AuthInfo: \"U:username@gmail.com\" \"P:password\" \"M:PLAIN\"\nI'd prefer a MTA that is able to do this on a per-user basis. My wish\nis something like procmail, but for sending. Some time ago I searched\nfor such an MTA, but unsuccessful. Does anyone know such a server?\n\nBest regards\nUwe\n\n-- \nUwe Kleine-König\n\ndd if=/proc/self/exe bs=1 skip=1 count=3 2>/dev/null\n"}]}