{"thread":{"id":"18297","subject":"Not pushing all branches?","startedAt":"2009-03-13T07:48:55Z","lastAt":"2009-03-17T08:24:57Z","messageCount":27,"participants":["Peter Krefting","Imran M Yousuf","John Tapsell","Johannes Schindelin","Finn Arne Gangstad","Michael J Gruber","Jeff King","Junio C Hamano","Miles Bader","Chris Johnsen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"107912","messageId":"alpine.DEB.2.00.0903130846410.17450@perkele.intern.softwolves.pp.se","threadId":"18297","inReplyTo":null,"subject":"Not pushing all branches?","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-03-13T07:48:55Z","receivedAt":"2009-03-13T07:48:55Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\nDoing \"git push remote\" pushes all my local branches by default. Is there a \nway to set it to *not* do that, and (for this particular remote repository) \njust push the current branch? Or failing that, not allow me to run \"git \npush\" without specifying a branch?\n\nThe git-config manual page leads me to believe that I should recofigure \n\"remote..push\", but it points me to the \"refspec\" spec on git-push, \nwhich is a tad cryptic.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"107914","messageId":"7bfdc29a0903130112w17d40473s14a895d518dbf8ae@mail.gmail.com","threadId":"18297","inReplyTo":"alpine.DEB.2.00.0903130846410.17450@perkele.intern.softwolves.pp.se","subject":"Re: Not pushing all branches?","fromName":"Imran M Yousuf","fromEmail":"imyousuf@gmail.com","sentAt":"2009-03-13T08:12:02Z","receivedAt":"2009-03-13T08:12:02Z","isPatch":false,"sender":{"key":"imyousuf@gmail.com","avatar":"https://gravatar.com/avatar/fda3c870262849d03c7b9c4d288842e128d6d80769fa7bc2d22731b7597928be?d=mp&s=160"},"body":"On Fri, Mar 13, 2009 at 1:48 PM, Peter Krefting wrote:\n> Hi!\n>\n> Doing \"git push remote\" pushes all my local branches by default. Is there a\n> way to set it to *not* do that, and (for this particular remote repository)\n> just push the current branch? Or failing that, not allow me to run \"git\n> push\" without specifying a branch?\n\nJust try -\ngit push remote branch :)\n\n>\n> The git-config manual page leads me to believe that I should recofigure\n> \"remote..push\", but it points me to the \"refspec\" spec on git-push,\n> which is a tad cryptic.\n>\n> --\n> \\\\// Peter - http://www.softwolves.pp.se/\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n\n\n\n-- \nImran M Yousuf\nEntrepreneur & Software Engineer\nSmart IT Engineering\nDhaka, Bangladesh\nEmail: imran@smartitengineering.com\nBlog: http://imyousuf-tech.blogs.smartitengineering.com/\nMobile: +880-1711402557\n"},{"id":"107917","messageId":"43d8ce650903130125m6335d189obbcdb86ec9036083@mail.gmail.com","threadId":"18297","inReplyTo":"alpine.DEB.2.00.0903130846410.17450@perkele.intern.softwolves.pp.se","subject":"Re: Not pushing all branches?","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-03-13T08:25:05Z","receivedAt":"2009-03-13T08:25:05Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/3/13 Peter Krefting :\n> Hi!\n>\n> Doing \"git push remote\" pushes all my local branches by default. Is there a\n> way to set it to *not* do that, and (for this particular remote repository)\n> just push the current branch?\n\n> Or failing that, not allow me to run \"git\n> push\" without specifying a branch?\n\nI've been pushing for this behaviour, and there was a patch a few days\nago to do this. I'm not sure if it is/will be committed.\n\nJohn Tapsell\n"},{"id":"107920","messageId":"alpine.DEB.2.00.0903131043510.17450@perkele.intern.softwolves.pp.se","threadId":"18297","inReplyTo":"7bfdc29a0903130112w17d40473s14a895d518dbf8ae@mail.gmail.com","subject":"Re: Not pushing all branches?","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-03-13T09:44:49Z","receivedAt":"2009-03-13T09:44:49Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Imran M Yousuf:\n\n> Just try -\n> git push remote branch :)\n\nThat is what I do. Unfortunately, the times I forged to name the branch, it \npushes my master branch, which is different from the remote's, and I have to \ngo to the other repository and reset it manually...\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"107927","messageId":"alpine.DEB.1.00.0903131148250.10279@pacific.mpi-cbg.de","threadId":"18297","inReplyTo":"alpine.DEB.2.00.0903131043510.17450@perkele.intern.softwolves.pp.se","subject":"Re: Not pushing all branches?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-13T10:49:08Z","receivedAt":"2009-03-13T10:49:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 13 Mar 2009, Peter Krefting wrote:\n\n> Imran M Yousuf:\n> \n> > Just try -\n> > git push remote branch :)\n> \n> That is what I do. Unfortunately, the times I forged to name the branch, \n> it pushes my master branch, which is different from the remote's, and I \n> have to go to the other repository and reset it manually...\n\nYou can set\n\n$ git config remote..push invalid-branch-name\n\nso that\n\n$ git push \n\nwill give you an error.\n\nCiao,\nDscho\n"},{"id":"107928","messageId":"alpine.DEB.1.00.0903131149200.10279@pacific.mpi-cbg.de","threadId":"18297","inReplyTo":"43d8ce650903130125m6335d189obbcdb86ec9036083@mail.gmail.com","subject":"Re: Not pushing all branches?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-13T10:51:52Z","receivedAt":"2009-03-13T10:51:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 13 Mar 2009, John Tapsell wrote:\n\n> 2009/3/13 Peter Krefting :\n>\n> > Doing \"git push remote\" pushes all my local branches by default. Is \n> > there a way to set it to *not* do that, and (for this particular \n> > remote repository) just push the current branch?\n> \n> > Or failing that, not allow me to run \"git push\" without specifying a \n> > branch?\n> \n> I've been pushing for this behaviour, and there was a patch a few days \n> ago to do this. I'm not sure if it is/will be committed.\n\nAs Junio is a careful maintainer, he will not change anything radical \nwhich would piss of a lot of people _without_ a proper, long-term plan \nthat gives users a chance.\n\nI know, I once tried to push for something like that, and I am glad that \nJunio is too wise as to make Git unstable for existing users.\n\nCiao,\nDscho\n"},{"id":"107934","messageId":"20090313113856.GA26726@pvv.org","threadId":"18297","inReplyTo":"alpine.DEB.2.00.0903131043510.17450@perkele.intern.softwolves.pp.se","subject":"Re: Not pushing all branches?","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-03-13T11:38:56Z","receivedAt":"2009-03-13T11:38:56Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Fri, Mar 13, 2009 at 10:44:49AM +0100, Peter Krefting wrote:\n> Imran M Yousuf:\n>\n>> Just try -\n>> git push remote branch :)\n>\n> That is what I do. Unfortunately, the times I forged to name the branch, \n> it pushes my master branch, which is different from the remote's, and I \n> have to go to the other repository and reset it manually...\n\nI sent a patch series a few days ago to fix this in various ways,\nadding a configuration variable push.default, and also indicating that\npushing nothing rather than pushing all matching branches is a safer\n(and saner) default.\n\nAs you have also discovered, it is very easy to accidentally push\nmaster to the wrong remote with the current default behavior.\n\n- Finn Arne\n"},{"id":"107936","messageId":"43d8ce650903130537r2459e1d2pef8fffc1c9b3fa5e@mail.gmail.com","threadId":"18297","inReplyTo":"alpine.DEB.1.00.0903131149200.10279@pacific.mpi-cbg.de","subject":"Re: Not pushing all branches?","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-03-13T12:37:42Z","receivedAt":"2009-03-13T12:37:42Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/3/13 Johannes Schindelin :\n> Hi,\n>\n> On Fri, 13 Mar 2009, John Tapsell wrote:\n>\n>> 2009/3/13 Peter Krefting :\n>>\n>> > Doing \"git push remote\" pushes all my local branches by default. Is\n>> > there a way to set it to *not* do that, and (for this particular\n>> > remote repository) just push the current branch?\n>>\n>> > Or failing that, not allow me to run \"git push\" without specifying a\n>> > branch?\n>>\n>> I've been pushing for this behaviour, and there was a patch a few days\n>> ago to do this.  I'm not sure if it is/will be committed.\n>\n> As Junio is a careful maintainer, he will not change anything radical\n> which would piss of a lot of people _without_ a proper, long-term plan\n> that gives users a chance.\n>\n> I know, I once tried to push for something like that, and I am glad that\n> Junio is too wise as to make Git unstable for existing users.\n\nUnderstandable. There were 6 patches, only the last one changes the\ndefault. Hopefully the first 5 will be applied and the 6 will\ndebated, then grudgingly applied :-)\n\nJohn\n"},{"id":"107946","messageId":"alpine.DEB.1.00.0903131452390.6288@intel-tinevez-2-302","threadId":"18297","inReplyTo":"43d8ce650903130537r2459e1d2pef8fffc1c9b3fa5e@mail.gmail.com","subject":"Re: Not pushing all branches?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-13T13:53:07Z","receivedAt":"2009-03-13T13:53:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 13 Mar 2009, John Tapsell wrote:\n\n> Hopefully the first 5 will be applied and the 6 will debated, then \n> grudgingly applied :-)\n\nNo. If it has to be applied grudgingly, it is most likely wrong.\n\nCiao,\nDscho\n"},{"id":"107947","messageId":"43d8ce650903130656p73e1e149s702f70466bbdb182@mail.gmail.com","threadId":"18297","inReplyTo":"alpine.DEB.1.00.0903131452390.6288@intel-tinevez-2-302","subject":"Re: Not pushing all branches?","fromName":"John Tapsell","fromEmail":"johnflux@gmail.com","sentAt":"2009-03-13T13:56:10Z","receivedAt":"2009-03-13T13:56:10Z","isPatch":false,"sender":{"key":"johnflux@gmail.com","avatar":"https://gravatar.com/avatar/25f70d4c0f96396b84a2e34bcd9bdc233462c7b4be29b5fdca8266fc53f30b0c?d=mp&s=160"},"body":"2009/3/13 Johannes Schindelin :\n> Hi,\n>\n> On Fri, 13 Mar 2009, John Tapsell wrote:\n>\n>> Hopefully the first 5 will be applied and the 6 will debated, then\n>> grudgingly applied :-)\n>\n> No.  If it has to be applied grudgingly, it is most likely wrong.\n\nIf there's an email about this every week from yet another person that\nhas been bitten by the current default, then the current default is\nmost likely wrong :-)\n\nJohn\n"},{"id":"107962","messageId":"49BA8067.6020902@drmicha.warpmail.net","threadId":"18297","inReplyTo":"43d8ce650903130656p73e1e149s702f70466bbdb182@mail.gmail.com","subject":"Re: Not pushing all branches?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-13T15:48:55Z","receivedAt":"2009-03-13T15:48:55Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"John Tapsell venit, vidit, dixit 13.03.2009 14:56:\n> 2009/3/13 Johannes Schindelin :\n>> Hi,\n>>\n>> On Fri, 13 Mar 2009, John Tapsell wrote:\n>>\n>>> Hopefully the first 5 will be applied and the 6 will debated, then\n>>> grudgingly applied :-)\n>>\n>> No. If it has to be applied grudgingly, it is most likely wrong.\n> \n> If there's an email about this every week from yet another person that\n> has been bitten by the current default, then the current default is\n> most likely wrong :-)\n\nI think I've used git every day this week, pushed several times, and\nstill have no bite-marks. Does this count as several votes in the other\ndirection?\n\nMichael\n"},{"id":"107963","messageId":"alpine.DEB.1.00.0903131657140.6288@intel-tinevez-2-302","threadId":"18297","inReplyTo":"43d8ce650903130656p73e1e149s702f70466bbdb182@mail.gmail.com","subject":"Re: Not pushing all branches?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-13T16:00:03Z","receivedAt":"2009-03-13T16:00:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 13 Mar 2009, John Tapsell wrote:\n\n> 2009/3/13 Johannes Schindelin :\n>\n> > On Fri, 13 Mar 2009, John Tapsell wrote:\n> >\n> >> Hopefully the first 5 will be applied and the 6 will debated, then \n> >> grudgingly applied :-)\n> >\n> > No.  If it has to be applied grudgingly, it is most likely wrong.\n> \n> If there's an email about this every week from yet another person that \n> has been bitten by the current default, then the current default is most \n> likely wrong :-)\n\nI suggest a different tack:\n\n- try to come up with a solution that does not bite anybody,\n\n- continue to modify the proposal until there are no objections left, and\n\n- continue to be liked on the list.\n\n;-)\n\nCiao,\nDscho\n"},{"id":"107968","messageId":"20090313164941.GA16504@sigill.intra.peff.net","threadId":"18297","inReplyTo":"alpine.DEB.2.00.0903130846410.17450@perkele.intern.softwolves.pp.se","subject":"Re: Not pushing all branches?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-13T16:49:41Z","receivedAt":"2009-03-13T16:49:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 13, 2009 at 08:48:55AM +0100, Peter Krefting wrote:\n\n> Doing \"git push remote\" pushes all my local branches by default. Is there \n> a way to set it to *not* do that, and (for this particular remote \n> repository) just push the current branch? Or failing that, not allow me to \n> run \"git push\" without specifying a branch?\n>\n> The git-config manual page leads me to believe that I should recofigure \n> \"remote..push\", but it points me to the \"refspec\" spec on git-push, \n> which is a tad cryptic.\n\nThere seem to be a lot of responses in this thread, but nobody has\nsuggested:\n\n git config remote.$remote.push HEAD\n\nIt isn't mentioned in the git-push manpage; maybe a documentation patch\nto give an example using HEAD would make sense?\n\n-Peff\n"},{"id":"107980","messageId":"7v4oxxgpil.fsf@gitster.siamese.dyndns.org","threadId":"18297","inReplyTo":"43d8ce650903130125m6335d189obbcdb86ec9036083@mail.gmail.com","subject":"Re: Not pushing all branches?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-13T20:02:26Z","receivedAt":"2009-03-13T20:02:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Tapsell writes:\n\n> 2009/3/13 Peter Krefting :\n>> Hi!\n>>\n>> Doing \"git push remote\" pushes all my local branches by default. Is there a\n>> way to set it to *not* do that, and (for this particular remote repository)\n>> just push the current branch?\n>\n>> Or failing that, not allow me to run \"git\n>> push\" without specifying a branch?\n>\n> I've been pushing for this behaviour, and there was a patch a few days\n> ago to do this. I'm not sure if it is/will be committed.\n\nThe current status of the series is roughly as follows:\n\n * Finn Arne sent out a 6 patch series that consists of:\n\n 0e118fe remote: Make \"-\" an alias for the current remote\n 5a18380 New config option push.default\n 0b9dcb9 git push: New options --matching and --current\n bf8552b git push: Display warning on unconfigured default push\n cf9d5ab git push: Document that \"nothing\" is the future push default\n 3c2bcc2 git push: Change default for \"git push\" to nothing.\n\n * The main topic of the series are patches 2, 4, 5, 6:\n\n - Introduce a new configuration push.default;\n\n - Issue a warning when push.default is not set and 'git push' is run\n without saying what refspecs to push, and tell the users that the\n warning can be squelched by setting the configuration (set it to\n 'matching' to keep the traditional, 'nothing' to get what Peter\n wants);\n\n - Reword the warning that the default will change to 'nothing';\n\n - Switch the default to 'nothing'.\n\n Which is a reasonable transition plan _if_ we were to change the\n default (except that I think the last one should still keep giving\n warning for people who learned git from the current documentation and\n the start using it after the default is changed).\n\n If you are changing the default, you have to make people who like the\n current \"matching\" behaviour suffer no matter how you go about it. The\n above \"start warning early, give chance to people to say 'I want to\n keep my default' before the default changes, and then finally change\n the default\" would ease the pain of transition for them. And the\n configuration option will help people who want new default to set it\n right away.\n\n * The series is queued in 'pu' for now, as it has a few issues (see mail\n archive for discussions):\n\n - The first \"-\" one; even though it may be useful to be able to say\n \"the remote the current branch is associated with by default\", using\n \"-\" as a short-hand for that might be harmful to the long term UI\n health, and further study was requested, which hasn't been responded\n yet.\n\n - The third \"--matching/--current\" one; --matching is unnecessary as we\n already have \":\", --current turns out to be different from HEAD and\n is misnamed. There also was somebody with an opinion that --current\n adds unnecessary complexity only to encourage a wrong workflow.\n\n In any case, these two do not have anything to do with the issue that\n \"'matching refs' behaviour of a lazy 'git push' that does not say what\n refspecs to push is not always a useful default\", and should be done as\n separate patches. They should come after the dust settles after either\n applying the first two of the main part of the series or deciding to\n drop the main part of the series.\n\n Also the last one needs to adjust the tests because majority of them\n rely on the current 'matching' behaviour. As the series lacks it,\n merging it all to 'pu' would make the result not pass the test suite,\n and I excluded the last few patches from 'pu' for now.\n\n The size of such a patch would be a rough indication how much pain you\n are proposing to incur on existing users.\n\n * Finn Arne sent the first one of a \"replacement\" patch series, which I\n looked at, but haven't had time to actually replace the ones that are\n queued in 'pu' (and I haven't seen the second and subsequent ones yet,\n so there is no rush on my end to do so at this moment).\n"},{"id":"107990","messageId":"874oxwgbcr.fsf@catnip.gol.com","threadId":"18297","inReplyTo":"7v4oxxgpil.fsf@gitster.siamese.dyndns.org","subject":"Re: Not pushing all branches?","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2009-03-14T01:08:20Z","receivedAt":"2009-03-14T01:08:20Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano writes:\n> - The first \"-\" one; even though it may be useful to be able to say\n> \"the remote the current branch is associated with by default\", using\n> \"-\" as a short-hand for that might be harmful to the long term UI\n> health, and further study was requested, which hasn't been responded\n> yet.\n\nI've often wished for such a thing in some contexts, actually...\ne.g., \"git diff REMOTE_BRANCH\" to see what updates are pending if I\nmerge... Also, it would be nice to have a more concise way to say\n\"git merge REMOTE_BRANCH\".\n\nI'm not sure \"-\" seems like the best syntax though... maybe it's a bit\n_too_ short.\n\n[Is there a general standard syntax for \"keywords\" in git, e.g., to\ndistinguish them from branch/rev names? I mean, if the standard syntax\nwere \"@foo\", then one could imagine \"git diff @remote\" or something.]\n\n-miles\n\n-- \nRun away! Run away!\n"},{"id":"107991","messageId":"1236994051-27346-1-git-send-email-chris_johnsen@pobox.com","threadId":"18297","inReplyTo":"20090313164941.GA16504@sigill.intra.peff.net","subject":"[PATCH] git-push.txt: describe how to default to pushing only current branch","fromName":"Chris Johnsen","fromEmail":"chris_johnsen@pobox.com","sentAt":"2009-03-14T01:27:31Z","receivedAt":"2009-03-14T01:27:31Z","isPatch":true,"sender":{"key":"chris_johnsen@pobox.com","avatar":"https://avatars.githubusercontent.com/u/107071?v=4"},"body":"---\nJeff King writes:\n> git config remote.$remote.push HEAD\n> \n> It isn't mentioned in the git-push manpage; maybe a documentation\n> patch to give an example using HEAD would make sense?\n\nHere is a patch. It also attempts to document bare 'git push'.\n\nIn the resulting manpage the inline commands are not very\nobvious (the HTML looks OK though). There is some sort of\nformatting in there, but it does not seem to display any\ndifferently from the surrounding text when I use man to view it\non my system. Would it be better to do something like wrap\ndouble quotes around the inline commands to help readers viewing\nthe manpage?\n---\n Documentation/git-push.txt | 26 ++++++++++++++++++++++++--\n 1 files changed, 24 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 4e7e5a7..fd53c49 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -24,8 +24,8 @@ every time you push into it, by setting up 'hooks' there. See\n documentation for linkgit:git-receive-pack[1].\n \n \n-OPTIONS\n--------\n+OPTIONS[[OPTIONS]]\n+------------------\n ::\n \tThe \"remote\" repository that is destination of a push\n \toperation. This parameter can be either a URL\n@@ -187,6 +187,28 @@ reason::\n Examples\n --------\n \n+git push::\n+\tWorks like `git push `, where is the\n+\tcurrent branch's remote (or `origin`, if no remote is\n+\tconfigured for the current branch).\n+\n+git push origin::\n+\tWithout additional configuration, works like\n+\t`git push origin :`.\n++\n+The default behavior of this command when no is given can be\n+configured by setting the `push` option of the remote.\n++\n+For example, to default to pushing only the current branch to `origin`\n+use `git config remote.origin.push HEAD`. Any valid (like\n+the ones in the examples below) can be configured as the default for\n+`git push origin`.\n+\n+git push origin :::\n+\tPush \"matching\" branches to `origin`. See\n+\t in the <> section above for a\n+\tdescription of \"matching\" branches.\n+\n git push origin master::\n \tFind a ref that matches `master` in the source repository\n \t(most likely, it would find `refs/heads/master`), and update\n-- \n1.6.2\n"},{"id":"108016","messageId":"7vd4cjc3da.fsf@gitster.siamese.dyndns.org","threadId":"18297","inReplyTo":"1236994051-27346-1-git-send-email-chris_johnsen@pobox.com","subject":"Re: [PATCH] git-push.txt: describe how to default to pushing only current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-14T19:26:41Z","receivedAt":"2009-03-14T19:26:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The new text looks reasonable. Sign-off?\n\nAny improvement suggestions from others?\n"},{"id":"108019","messageId":"20090314203434.GA15444@coredump.intra.peff.net","threadId":"18297","inReplyTo":"7vd4cjc3da.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-push.txt: describe how to default to pushing only current branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-14T20:34:35Z","receivedAt":"2009-03-14T20:34:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 13, 2009 at 08:27:31PM -0500, Chris Johnsen wrote:\n\n> In the resulting manpage the inline commands are not very\n> obvious (the HTML looks OK though). There is some sort of\n> formatting in there, but it does not seem to display any\n> differently from the surrounding text when I use man to view it\n> on my system. Would it be better to do something like wrap\n> double quotes around the inline commands to help readers viewing\n> the manpage?\n\nThe problem is that they are supposed to set in a monospaced font, but\nmost terminals are already monospaced. This is actually a problem\nthroughout the documentation, although it is usually only for\nsingle-word phrases (like `git-foo`), which don't look nearly as bad as\nmulti-word ones.\n\nActually, looking closer, the information seems to be lost entirely.\nAsciidoc renders this to in the XML, but docbook seems to\nthrow it away when converting to a manpage. In theory it's possible to\napply our own xsl style to turn this into something else, and I think\nthat is a better solution than just trying to fix this one spot.\n\nThe question is how it _should_ be rendered. Monospace isn't really\nuseful for terminals. Maybe simply putting quotation marks around it\nwould cover all situations (I'm worried it will look funny for\nsingle-word instances).\n\n\nOn Sat, Mar 14, 2009 at 12:26:41PM -0700, Junio C Hamano wrote:\n\n> The new text looks reasonable. Sign-off?\n> \n> Any improvement suggestions from others?\n\nIt looks fine to me; my only concern is the typesetting, but I think\nthat should be fixed elsewhere, as outlined above.\n\n-Peff\n"},{"id":"108023","messageId":"20090314205628.GA17445@coredump.intra.peff.net","threadId":"18297","inReplyTo":"20090314203434.GA15444@coredump.intra.peff.net","subject":"Re: [PATCH] git-push.txt: describe how to default to pushing only current branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-14T20:56:28Z","receivedAt":"2009-03-14T20:56:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 14, 2009 at 04:34:34PM -0400, Jeff King wrote:\n\n> The question is how it _should_ be rendered. Monospace isn't really\n> useful for terminals. Maybe simply putting quotation marks around it\n> would cover all situations (I'm worried it will look funny for\n> single-word instances).\n\nAnd here's a patch that does that; skimming through the output it\ndoesn't look too bad. What do you guys think?\n\n---\ndiff --git a/Documentation/callouts.xsl b/Documentation/callouts.xsl\nindex 6a361a2..01df100 100644\n--- a/Documentation/callouts.xsl\n+++ b/Documentation/callouts.xsl\n@@ -27,4 +27,6 @@\n \n \n \n+\"\"\n+\n \n"},{"id":"108026","messageId":"7veiwzajbc.fsf@gitster.siamese.dyndns.org","threadId":"18297","inReplyTo":"20090314203434.GA15444@coredump.intra.peff.net","subject":"Re: [PATCH] git-push.txt: describe how to default to pushing only current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-14T21:25:11Z","receivedAt":"2009-03-14T21:25:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Actually, looking closer, the information seems to be lost entirely.\n> Asciidoc renders this to in the XML, but docbook seems to\n> throw it away when converting to a manpage. In theory it's possible to\n> apply our own xsl style to turn this into something else, and I think\n> that is a better solution than just trying to fix this one spot.\n\nWhen I check the asciidoc output for manpages (which I rarely do), I often\nrender it to Postscript to see the typesetting. I guess not many people\nconsider manpages are for printing anymore but are solely for monospaced\nterminal consumption these days.\n"},{"id":"108028","messageId":"20090314214603.GA20418@sigill.intra.peff.net","threadId":"18297","inReplyTo":"7veiwzajbc.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-push.txt: describe how to default to pushing only current branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-14T21:46:03Z","receivedAt":"2009-03-14T21:46:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 14, 2009 at 02:25:11PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Actually, looking closer, the information seems to be lost entirely.\n> > Asciidoc renders this to in the XML, but docbook seems to\n> > throw it away when converting to a manpage. In theory it's possible to\n> > apply our own xsl style to turn this into something else, and I think\n> > that is a better solution than just trying to fix this one spot.\n> \n> When I check the asciidoc output for manpages (which I rarely do), I often\n> render it to Postscript to see the typesetting. I guess not many people\n> consider manpages are for printing anymore but are solely for monospaced\n> terminal consumption these days.\n\nHow do you render it? From the XML, or from the roff? Because if I am\nreading it right (which it is entirely possible that I am not), the\ninformation is lost in the roff version. And that is the version I would\nexpect people to be looking at (via man -Tps, or just plain man).\n\n-Peff\n"},{"id":"108031","messageId":"1237084321-14492-1-git-send-email-chris_johnsen@pobox.com","threadId":"18297","inReplyTo":"7vd4cjc3da.fsf@gitster.siamese.dyndns.org","subject":"[PATCH v2] git-push.txt: describe how to default to pushing only current branch","fromName":"Chris Johnsen","fromEmail":"chris_johnsen@pobox.com","sentAt":"2009-03-15T02:32:01Z","receivedAt":"2009-03-15T02:32:01Z","isPatch":true,"sender":{"key":"chris_johnsen@pobox.com","avatar":"https://avatars.githubusercontent.com/u/107071?v=4"},"body":"Signed-off-by: Chris Johnsen \n---\nOn 2009 Mar 14, at 14:26, Junio C Hamano wrote:\n> The new text looks reasonable. Sign-off?\n\nOops, sorry for the omission. Here it is again with the S-o-B (or\ninsert it by hand if you like).\n---\n Documentation/git-push.txt | 26 ++++++++++++++++++++++++--\n 1 files changed, 24 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 4e7e5a7..fd53c49 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -24,8 +24,8 @@ every time you push into it, by setting up 'hooks' there. See\n documentation for linkgit:git-receive-pack[1].\n \n \n-OPTIONS\n--------\n+OPTIONS[[OPTIONS]]\n+------------------\n ::\n \tThe \"remote\" repository that is destination of a push\n \toperation. This parameter can be either a URL\n@@ -187,6 +187,28 @@ reason::\n Examples\n --------\n \n+git push::\n+\tWorks like `git push `, where is the\n+\tcurrent branch's remote (or `origin`, if no remote is\n+\tconfigured for the current branch).\n+\n+git push origin::\n+\tWithout additional configuration, works like\n+\t`git push origin :`.\n++\n+The default behavior of this command when no is given can be\n+configured by setting the `push` option of the remote.\n++\n+For example, to default to pushing only the current branch to `origin`\n+use `git config remote.origin.push HEAD`. Any valid (like\n+the ones in the examples below) can be configured as the default for\n+`git push origin`.\n+\n+git push origin :::\n+\tPush \"matching\" branches to `origin`. See\n+\t in the <> section above for a\n+\tdescription of \"matching\" branches.\n+\n git push origin master::\n \tFind a ref that matches `master` in the source repository\n \t(most likely, it would find `refs/heads/master`), and update\n-- \n1.6.2\n"},{"id":"108032","messageId":"1237085349-14824-1-git-send-email-chris_johnsen@pobox.com","threadId":"18297","inReplyTo":"20090314205628.GA17445@coredump.intra.peff.net","subject":"Re: [PATCH] git-push.txt: describe how to default to pushing only current branch","fromName":"Chris Johnsen","fromEmail":"chris_johnsen@pobox.com","sentAt":"2009-03-15T02:49:09Z","receivedAt":"2009-03-15T02:49:09Z","isPatch":true,"sender":{"key":"chris_johnsen@pobox.com","avatar":"https://avatars.githubusercontent.com/u/107071?v=4"},"body":"On 2009 Mar 14, at 15:56, Jeff King wrote:\n> On Sat, Mar 14, 2009 at 04:34:34PM -0400, Jeff King wrote:\n> > The question is how it _should_ be rendered. Monospace isn't really\n> > useful for terminals. Maybe simply putting quotation marks around it\n> > would cover all situations (I'm worried it will look funny for\n> > single-word instances).\n>\n> And here's a patch that does that; skimming through the output it\n> doesn't look too bad. What do you guys think?\n>\n> ---\n\nThe presentation seems OK to me. I thought of two issues:\n\n1) literals that contain a double quote\n\n\t$ git grep '`[^`]*\"[^`]`' | cat\n\tconfig.txt:You can have `[section]` if you have `[section \"subsection\"]`, but you\n\n There might be a better regexp to find these, I did not think\n about it too long. The above \"hit\" seems like a reasonable\n literal string. Maybe it is OK to live with this one\n (\"[section \"subsection\"]\").\n\n2) manpage-1.72.xsl \n\n I have been setting DOCBOOK_XSL_172 to avoid the \".ft\" problem\n (;\n my system is Mac OS X 10.4.11 with MacPorts asciidoc 8.3.1,\n xmlto version 0.0.21, and docbook-xsl 1.74.0). Since non-null\n DOCBOOK_XSL_172 replaces callouts.xsl with manpage-1.72.xsl, I\n added the line to manpage-1.72.xsl.\n\n Here is the patch if it is deemed appropriate (same line Peff\n added to callouts.xsl):\n\n-- >8 -- \nSubject: [PATCH] manpage-1.72.xsl: wrap inline literal text with double quotes\n\nSigned-off-by: Chris Johnsen \n---\n Documentation/manpage-1.72.xsl | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/manpage-1.72.xsl b/Documentation/manpage-1.72.xsl\nindex 4065a3a..a39fd55 100644\n--- a/Documentation/manpage-1.72.xsl\n+++ b/Documentation/manpage-1.72.xsl\n@@ -18,4 +18,6 @@\n \t⌂br \n \n \n+\"\"\n+\n \n-- \n1.6.2\n"},{"id":"108039","messageId":"1237116652-24716-1-git-send-email-chris_johnsen@pobox.com","threadId":"18297","inReplyTo":"1237085349-14824-1-git-send-email-chris_johnsen@pobox.com","subject":"Re: [PATCH] git-push.txt: describe how to default to pushing only","fromName":"Chris Johnsen","fromEmail":"chris_johnsen@pobox.com","sentAt":"2009-03-15T11:30:52Z","receivedAt":"2009-03-15T11:30:52Z","isPatch":true,"sender":{"key":"chris_johnsen@pobox.com","avatar":"https://avatars.githubusercontent.com/u/107071?v=4"},"body":"On 2009 Mar 14, at 21:49, Chris Johnsen wrote:\n> On 2009 Mar 14, at 15:56, Jeff King wrote:\n> > On Sat, Mar 14, 2009 at 04:34:34PM -0400, Jeff King wrote:\n> > > The question is how it _should_ be rendered. Monospace isn't really\n> > > useful for terminals. Maybe simply putting quotation marks around it\n> > > would cover all situations (I'm worried it will look funny for\n> > > single-word instances).\n> >\n> > And here's a patch that does that; skimming through the output it\n> > doesn't look too bad. What do you guys think?\n> >\n> > ---\n>\n> The presentation seems OK to me. I thought of two issues:\n>\n> 1) literals that contain a double quote\n>\n> \t$ git grep '`[^`]*\"[^`]`' | cat\n> \tconfig.txt:You can have `[section]` if you have `[section \"subsection\"]`, but you\n>\n> There might be a better regexp to find these, I did not think\n> about it too long. The above \"hit\" seems like a reasonable\n\nOf course the above regexp fails miserably since there are many\nother instances of `...\"...` in the documentation. I eventually\nended up using this one:\n\n\tgit grep -e \"\\`.*['\\\"]\" -e \"['\\\"].*\\`\" master -- Documentation\n\nIt catches a lot more than just \"`...`\" and `\"...\"`, but I tried\nto plow through it all. I turns out that there are lots of\ninstances of double quotes inside or just outside backticks in\nthe documentation.\n\nI edited out all the ones that did not seem to be meaningful. But\nthere are still many places where there is a meaningful double\nquote inside a literal section. So, I think the workaround of\nwrapping double quotes around manpage-destined literal sections\nmay not work well.\n\nA patch to remove much of the extra quoting/emphasis\naround/inside literal sections follows, but it will likely\nnegatively affect the manpages unless we can find a different way\nto render the literal sections in manpages. It seems likely that\nthis patch should just be \"parked\" in the list archives until\nsomeone can work out a way to emphasize the literal sections for\nmanpages.\n\nThe '`...`' style used in parts of config.txt yields underlined\ntext in my terminal-based view of the manpage. If underlining (or\nwhatever other formatting) could be applied to manpage-destined\nliteral text, that might work out better. I have not yet searched\nfor a way to make that happen through XSL. It might be as simple\nas taking Peff's approach and using \\fI and \\fR instead of double\nquotes (codes taken from other text that shows up as underlined\non my system; also the more I look into the asciidoc/docbook\nstuff, the less I think anything involving more than one version\ncan be \"simple\").\n\n-- >8 --\nSubject: [PATCH] Documentation: remove extra quoting/emphasis around literal texts\n\nIf literal text (asciidoc `...`) can be rendered in a differently from\nnormal text for each output format (man, HTML), then we do not need\nextra quotes or other wrapping around inline literal text segments.\n\nconfig.txt\n\n Change '`...`' to `...`. In asciidoc, the single quotes provide\n emphasis, literal text should be distintive enough.\n\n Change \"`...`\" to `...`. These double quotes do not work if present\n in the described config value, so drop them.\n\ngit-checkout.txt\n\n Change \"`...`\" to `...` or `\"...\"`. All instances are command line\n argument examples. One \"`-`\" becomes `-`. Two others are involve\n curly braces, so move the double quotes inside the literal region to\n indicate that they might need to be quoted on the command line of\n certain shells (tcsh).\n\ngit-merge.txt\n\n Change \"`...`\" to `...`. All instances are used to describe merge\n conflict markers. The quotes should are not important.\n\ngit-rev-parse.txt\n\n Change \"`...`\" to `...`. All instances are around command line\n arguments where no in-shell quoting should be necessary.\n\ngitcli.txt\n\n Change `\"...\"` to `...`. All instances are around command line\n examples or single command arguments. They do not semanticly belong\n inside the literal text, and they are not needed outside it.\n\nglossary-content.txt\nuser-manual.txt\n\n Change \"`...`\" to `...`. All instances were around command lines.\n\nSigned-off-by: Chris Johnsen \n---\n Documentation/config.txt | 24 ++++++++++++------------\n Documentation/git-checkout.txt | 4 ++--\n Documentation/git-merge.txt | 6 +++---\n Documentation/git-rev-parse.txt | 8 ++++----\n Documentation/gitcli.txt | 24 ++++++++++++------------\n Documentation/glossary-content.txt | 2 +-\n Documentation/user-manual.txt | 6 +++---\n 7 files changed, 37 insertions(+), 37 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 14f861a..11f37d3 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -25,7 +25,7 @@ blank lines are ignored.\n The file consists of sections and variables. A section begins with\n the name of the section in square brackets and continues until the next\n section begins. Section names are not case sensitive. Only alphanumeric\n-characters, '`-`' and '`.`' are allowed in section names. Each variable\n+characters, `-` and `.` are allowed in section names. Each variable\n must belong to some section, which means that there must be section\n header before first setting of a variable.\n \n@@ -39,7 +39,7 @@ in the section header, like in example below:\n --------\n \n Subsection names can contain any characters except newline (doublequote\n-'`\"`' and backslash have to be escaped as '`\\\"`' and '`\\\\`',\n+`\"` and backslash have to be escaped as `\\\"` and `\\\\`,\n respectively) and are case sensitive. Section header cannot span multiple\n lines. Variables may belong directly to a section or to a given subsection.\n You can have `[section]` if you have `[section \"subsection\"]`, but you\n@@ -53,7 +53,7 @@ All the other lines are recognized as setting variables, in the form\n 'name = value'. If there is no equal sign on the line, the entire line\n is taken as 'name' and the variable is recognized as boolean \"true\".\n The variable names are case-insensitive and only alphanumeric\n-characters and '`-`' are allowed. There can be more than one value\n+characters and `-` are allowed. There can be more than one value\n for a given variable; we say then that variable is multivalued.\n \n Leading and trailing whitespace in a variable value is discarded.\n@@ -69,15 +69,15 @@ String values may be entirely or partially enclosed in double quotes.\n You need to enclose variable value in double quotes if you want to\n preserve leading or trailing whitespace, or if variable value contains\n beginning of comment characters (if it contains '#' or ';').\n-Double quote '`\"`' and backslash '`\\`' characters in variable value must\n-be escaped: use '`\\\"`' for '`\"`' and '`\\\\`' for '`\\`'.\n+Double quote `\"` and backslash `\\` characters in variable value must\n+be escaped: use `\\\"` for `\"` and `\\\\` for `\\`.\n \n-The following escape sequences (beside '`\\\"`' and '`\\\\`') are recognized:\n-'`\\n`' for newline character (NL), '`\\t`' for horizontal tabulation (HT, TAB)\n-and '`\\b`' for backspace (BS). No other char escape sequence, nor octal\n+The following escape sequences (beside `\\\"` and `\\\\`) are recognized:\n+`\\n` for newline character (NL), `\\t` for horizontal tabulation (HT, TAB)\n+and `\\b` for backspace (BS). No other char escape sequence, nor octal\n char sequences are valid.\n \n-Variable value ending in a '`\\`' is continued on the next line in the\n+Variable value ending in a `\\` is continued on the next line in the\n customary UNIX fashion.\n \n Some variables may require special value format.\n@@ -382,9 +382,9 @@ core.pager::\n \tto override git's default settings this way, you need\n \tto be explicit. For example, to disable the S option\n \tin a backward compatible manner, set `core.pager`\n-\tto \"`less -+$LESS -FRX`\". This will be passed to the\n+\tto `less -+$LESS -FRX`. This will be passed to the\n \tshell by git, which will translate the final command to\n-\t\"`LESS=FRSX less -+FRSX -FRX`\".\n+\t`LESS=FRSX less -+FRSX -FRX`.\n \n core.whitespace::\n \tA comma separated list of common whitespace problems to\n@@ -1161,7 +1161,7 @@ pager.::\n \tparticular git subcommand when writing to a tty. If\n \t`\\--paginate` or `\\--no-pager` is specified on the command line,\n \tit takes precedence over this option. To disable pagination for\n-\tall commands, set `core.pager` or 'GIT_PAGER' to \"`cat`\".\n+\tall commands, set `core.pager` or `GIT_PAGER` to `cat`.\n \n pull.octopus::\n \tThe default merge strategy to use when pulling multiple branches\ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex 125d8f3..1a6c19e 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -133,9 +133,9 @@ the conflicted merge in the specified paths.\n When this parameter names a non-branch (but still a valid commit object),\n your HEAD becomes 'detached'.\n +\n-As a special case, the \"`@\\{-N\\}`\" syntax for the N-th last branch\n+As a special case, the `\"@\\{-N\\}\"` syntax for the N-th last branch\n checks out the branch (instead of detaching). You may also specify\n-\"`-`\" which is synonymous with \"`@\\{-1\\}`\".\n+`-` which is synonymous with `\"@\\{-1\\}\"`.\n \n \n Detached HEAD\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex f7be584..cc0d30f 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -146,7 +146,7 @@ And here is another line that is cleanly resolved or unmodified.\n ------------\n \n The area where a pair of conflicting changes happened is marked with markers\n-\"`<<<<<<<`\", \"`=======`\", and \"`>>>>>>>`\". The part before the \"`=======`\"\n+`<<<<<<<`, `=======`, and `>>>>>>>`. The part before the `=======`\n is typically your side, and the part afterwards is typically their side.\n \n The default format does not show what the original said in the conflicting\n@@ -173,8 +173,8 @@ Git makes conflict resolution easy.\n And here is another line that is cleanly resolved or unmodified.\n ------------\n \n-In addition to the \"`<<<<<<<`\", \"`=======`\", and \"`>>>>>>>`\" markers, it uses\n-another \"`|||||||`\" marker that is followed by the original text. You can\n+In addition to the `<<<<<<<`, `=======`, and `>>>>>>>` markers, it uses\n+another `|||||||` marker that is followed by the original text. You can\n tell that the original just stated a fact, and your side simply gave in to\n that statement and gave up, while the other side tried to have a more\n positive attitude. You can sometimes come up with a better resolution by\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex 3ccef2f..5ed2bc8 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -299,18 +299,18 @@ previous section means the set of commits reachable from that\n commit, following the commit ancestry chain.\n \n To exclude commits reachable from a commit, a prefix `{caret}`\n-notation is used. E.g. \"`{caret}r1 r2`\" means commits reachable\n+notation is used. E.g. `{caret}r1 r2` means commits reachable\n from `r2` but exclude the ones reachable from `r1`.\n \n This set operation appears so often that there is a shorthand\n for it. When you have two commits `r1` and `r2` (named according\n to the syntax explained in SPECIFYING REVISIONS above), you can ask\n for commits that are reachable from r2 excluding those that are reachable\n-from r1 by \"`{caret}r1 r2`\" and it can be written as \"`r1..r2`\".\n+from r1 by `{caret}r1 r2` and it can be written as `r1..r2`.\n \n-A similar notation \"`r1\\...r2`\" is called symmetric difference\n+A similar notation `r1\\...r2` is called symmetric difference\n of `r1` and `r2` and is defined as\n-\"`r1 r2 --not $(git merge-base --all r1 r2)`\".\n+`r1 r2 --not $(git merge-base --all r1 r2)`.\n It is the set of commits that are reachable from either one of\n `r1` or `r2` but not from both.\n \ndiff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\nindex 29e5929..be39ed7 100644\n--- a/Documentation/gitcli.txt\n+++ b/Documentation/gitcli.txt\n@@ -46,20 +46,20 @@ Here are the rules regarding the \"flags\" that you should follow when you are\n scripting git:\n \n * it's preferred to use the non dashed form of git commands, which means that\n- you should prefer `\"git foo\"` to `\"git-foo\"`.\n+ you should prefer `git foo` to `git-foo`.\n \n- * splitting short options to separate words (prefer `\"git foo -a -b\"`\n- to `\"git foo -ab\"`, the latter may not even work).\n+ * splitting short options to separate words (prefer `git foo -a -b`\n+ to `git foo -ab`, the latter may not even work).\n \n * when a command line option takes an argument, use the 'sticked' form. In\n- other words, write `\"git foo -oArg\"` instead of `\"git foo -o Arg\"` for short\n- options, and `\"git foo --long-opt=Arg\"` instead of `\"git foo --long-opt Arg\"`\n+ other words, write `git foo -oArg` instead of `git foo -o Arg` for short\n+ options, and `git foo --long-opt=Arg` instead of `git foo --long-opt Arg`\n for long options. An option that takes optional option-argument must be\n written in the 'sticked' form.\n \n * when you give a revision parameter to a command, make sure the parameter is\n not ambiguous with a name of a file in the work tree. E.g. do not write\n- `\"git log -1 HEAD\"` but write `\"git log -1 HEAD --\"`; the former will not work\n+ `git log -1 HEAD` but write `git log -1 HEAD --`; the former will not work\n if you happen to have a file called `HEAD` in the work tree.\n \n \n@@ -99,17 +99,17 @@ usage: git-describe [options] *\n \n Negating options\n ~~~~~~~~~~~~~~~~\n-Options with long option names can be negated by prefixing `\"--no-\"`. For\n-example, `\"git branch\"` has the option `\"--track\"` which is 'on' by default. You\n-can use `\"--no-track\"` to override that behaviour. The same goes for `\"--color\"`\n-and `\"--no-color\"`.\n+Options with long option names can be negated by prefixing `--no-`. For\n+example, `git branch` has the option `--track` which is 'on' by default. You\n+can use `--no-track` to override that behaviour. The same goes for `--color`\n+and `--no-color`.\n \n \n Aggregating short options\n ~~~~~~~~~~~~~~~~~~~~~~~~~\n Commands that support the enhanced option parser allow you to aggregate short\n-options. This means that you can for example use `\"git rm -rf\"` or\n-`\"git clean -fdx\"`.\n+options. This means that you can for example use `git rm -rf` or\n+`git clean -fdx`.\n \n \n Separating argument from the option\ndiff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt\nindex 9afca75..4fc1cf1 100644\n--- a/Documentation/glossary-content.txt\n+++ b/Documentation/glossary-content.txt\n@@ -262,7 +262,7 @@ This commit is referred to as a \"merge commit\", or sometimes just a\n \t'origin' is used for that purpose. New upstream updates\n \twill be fetched into remote <> named\n \torigin/name-of-upstream-branch, which you can see using\n-\t\"`git branch -r`\".\n+\t`git branch -r`.\n \n [[def_pack]]pack::\n \tA set of objects which have been compressed into one file (to save space\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex 96af897..e33b29b 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -1136,10 +1136,10 @@ Ignoring files\n A project will often generate files that you do 'not' want to track with git.\n This typically includes files generated by a build process or temporary\n backup files made by your editor. Of course, 'not' tracking files with git\n-is just a matter of 'not' calling \"`git-add`\" on them. But it quickly becomes\n+is just a matter of 'not' calling `git-add` on them. But it quickly becomes\n annoying to have these untracked files lying around; e.g. they make\n-\"`git add .`\" practically useless, and they keep showing up in the output of\n-\"`git status`\".\n+`git add .` practically useless, and they keep showing up in the output of\n+`git status`.\n \n You can tell git to ignore certain files by creating a file called .gitignore\n in the top level of your working directory, with contents such as:\n-- \n1.6.2\n"},{"id":"108065","messageId":"7v4oxu135f.fsf@gitster.siamese.dyndns.org","threadId":"18297","inReplyTo":"20090314214603.GA20418@sigill.intra.peff.net","subject":"Re: [PATCH] git-push.txt: describe how to default to pushing only current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-16T04:51:24Z","receivedAt":"2009-03-16T04:51:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sat, Mar 14, 2009 at 02:25:11PM -0700, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > Actually, looking closer, the information seems to be lost entirely.\n>> > Asciidoc renders this to in the XML, but docbook seems to\n>> > throw it away when converting to a manpage. In theory it's possible to\n>> > apply our own xsl style to turn this into something else, and I think\n>> > that is a better solution than just trying to fix this one spot.\n>> \n>> When I check the asciidoc output for manpages (which I rarely do), I often\n>> render it to Postscript to see the typesetting. I guess not many people\n>> consider manpages are for printing anymore but are solely for monospaced\n>> terminal consumption these days.\n>\n> How do you render it? From the XML, or from the roff? Because if I am\n> reading it right (which it is entirely possible that I am not), the\n> information is lost in the roff version. And that is the version I would\n> expect people to be looking at (via man -Tps, or just plain man).\n\nI was agreeing with you; I let \"man -Tps -l git-foo.1\" render from roff\ninput and I can see that the output from asciidoc toolchain) prepared as\nroff input does not consider printed pages so important anymore.\n"},{"id":"108188","messageId":"20090317074633.GB18475@coredump.intra.peff.net","threadId":"18297","inReplyTo":"1237085349-14824-1-git-send-email-chris_johnsen@pobox.com","subject":"Re: [PATCH] git-push.txt: describe how to default to pushing only current branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-17T07:46:33Z","receivedAt":"2009-03-17T07:46:33Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 14, 2009 at 09:49:09PM -0500, Chris Johnsen wrote:\n\n> 1) literals that contain a double quote\n> \n> \t$ git grep '`[^`]*\"[^`]`' | cat\n> \tconfig.txt:You can have `[section]` if you have `[section \"subsection\"]`, but you\n> \n> There might be a better regexp to find these, I did not think\n> about it too long. The above \"hit\" seems like a reasonable\n> literal string. Maybe it is OK to live with this one\n> (\"[section \"subsection\"]\").\n\nHmm, good point. Something with typeface that could not be in the string\ncontents would probably be a better choice. The linkgit: links appear\nbolded. We could do that. We could also try underlining, though that\nmight be hard to read if any strings contained underscores.\n\nI tried to find examples of other manpages that faced the same problem.\nI would guess that bold is the best bet (for example, the 'cat' manpage\non my system looks like (excuse my fake markup):\n\n -A, --show-all\n equivalent to -vET\n\n> 2) manpage-1.72.xsl \n> \n> I have been setting DOCBOOK_XSL_172 to avoid the \".ft\" problem\n> (;\n> my system is Mac OS X 10.4.11 with MacPorts asciidoc 8.3.1,\n> xmlto version 0.0.21, and docbook-xsl 1.74.0). Since non-null\n> DOCBOOK_XSL_172 replaces callouts.xsl with manpage-1.72.xsl, I\n> added the line to manpage-1.72.xsl.\n\nThe \"callouts\" XSL is obviously becoming more than that (there is\nalready a \"I know, this is not a callout, but where else to put it?\"\ncomment in it). It probably makes sense to rename it to manpage.xsl (or\neven manpage-1.8.xsl), factor out common parts to manpage-base.xsl, and\nthen include the -base version from both manpage and manpage-1.72.xsl.\n\nWant to do a patch?\n\n-Peff\n"},{"id":"108193","messageId":"20090317082457.GG18475@coredump.intra.peff.net","threadId":"18297","inReplyTo":"874oxwgbcr.fsf@catnip.gol.com","subject":"Re: Not pushing all branches?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-17T08:24:57Z","receivedAt":"2009-03-17T08:24:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 14, 2009 at 10:08:20AM +0900, Miles Bader wrote:\n\n> e.g., \"git diff REMOTE_BRANCH\" to see what updates are pending if I\n> merge... Also, it would be nice to have a more concise way to say\n> \"git merge REMOTE_BRANCH\".\n> \n> I'm not sure \"-\" seems like the best syntax though... maybe it's a bit\n> _too_ short.\n> \n> [Is there a general standard syntax for \"keywords\" in git, e.g., to\n> distinguish them from branch/rev names? I mean, if the standard syntax\n> were \"@foo\", then one could imagine \"git diff @remote\" or something.]\n\nI think all-caps is the closest we get. E.g., you probably don't want to\nname a branch MERGE_HEAD, ORIG_HEAD, FETCH_HEAD, etc. But it's purely\nadvisory; you _can_ make such branches and then deal with the ensuing\n\"ambiguous ref\" messages.\n\n-Peff\n"}]}