{"thread":{"id":"30428","subject":"git-scm.com refresh","startedAt":"2012-05-04T23:29:33Z","lastAt":"2012-05-09T22:13:43Z","messageCount":28,"participants":["Scott Chacon","Jakub Narebski","Junio C Hamano","Andrew Sayers","Felipe Contreras","Philip Oakley","Josh Juran","Neal Kreitzinger","Matthieu Moy","Christian Couder","A Large Angry SCM","Ævar Arnfjörð Bjarmason","Antonio Ospite","Andreas Schwab","Heiko Voigt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"190811","messageId":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","threadId":"30428","inReplyTo":null,"subject":"git-scm.com refresh","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2012-05-04T23:29:33Z","receivedAt":"2012-05-04T23:29:33Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey everyone,\n\nI just shipped a big update to the git-scm.com website, incorporating\ntons of feedback I've gotten on the site, especially from new users,\nover the years.  I think it will help new users to Git find the right\ninstaller and get up and running easier.  I have other ideas of things\nto add to it in the future, but I think this is much better than the\nsite that has served us well for a few years now.\n\nSome other interesting things to note:\n\n* There is now permanent man page hosting here, for example:\nhttp://git-scm.com/docs/git-fsck.  You can also reference any older\nversion of any command: http://git-scm.com/docs/git-fsck/1.5.5\n\n* We designed a new logo[1] - there are multiple variations available\nfor download on the site under the most permissive CC license for any\nuse.\n\n* The Pro Git book (and all of it's translations) has been directly\nincorporated into the site and has better permalinks and section\nanchors.  progit.org will soon be redirecting to git-scm.com.\n\n* Matthew McCullough has started a video series[2] for newbies and\nwill continue to do more developer and intermediate type videos as\nwell.\n\n* There are still a few asciidoc parsing issues that we're working on\n- if you find anything that's weird please report it at our issue\ntracker: https://github.com/github/gitscm-next/issues\n\nLet me know if you run into anything or there are any features you\nwould like to see.  Also, be sure to thank Jason Long for doing all\nthe design for the site, including the new logo\n(https://github.com/blackant).\n\nScott\n\n[1] http://git-scm.com/downloads/logos\n[2] http://git-scm.com/videos\n"},{"id":"190813","messageId":"m38vh7qxs3.fsf@localhost.localdomain","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-05-05T00:26:07Z","receivedAt":"2012-05-05T00:26:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Scott Chacon <schacon@gmail.com> writes:\n\n> Hey everyone,\n> \n> I just shipped a big update to the git-scm.com website, incorporating\n> tons of feedback I've gotten on the site, especially from new users,\n> over the years.  I think it will help new users to Git find the right\n> installer and get up and running easier.  I have other ideas of things\n> to add to it in the future, but I think this is much better than the\n> site that has served us well for a few years now.\n> \n> Some other interesting things to note:\n> \n> * There is now permanent man page hosting here, for example:\n> http://git-scm.com/docs/git-fsck.  You can also reference any older\n> version of any command: http://git-scm.com/docs/git-fsck/1.5.5\n\nThat's very good.  Thank you very much for giving home to git manpages\nonline.\n\nIt would be nice for those manpages to have the title of page to be\nset appropriately, e.g. for http://git-scm.com/docs/git-bisect to have\n\"git-bisect(1)\" or \"git-bisect(1) Manual Page\", or even perhaps\n\"git-bisect(1) Manual Page - Find by binary search the change that\nintroduced a bug\" instead of just \"Git\".\n\n> \n> * We designed a new logo[1] - there are multiple variations available\n> for download on the site under the most permissive CC license for any\n> use.\n\nIMVHO it is too similar to Bazaar logo:\n\n  http://bazaar.canonical.com/bzricons/bazaar-logo.png\n\nI like the [---] git logo, but I guess it is a bit cryptic.\n           [+++]\n\n\n[...]\n> Let me know if you run into anything or there are any features you\n> would like to see.\n\nIn my ancient 10-years old web browser (Mozilla 1.17.2, Linux) the new\nlayout is seriously broken (misaligned), and much less readable than\nthe old one (BTW. could you keep the old one, perhaps only the front\npage, for comparison?).  Also the font size is too small.\n\n-- \nJakub Narebski\n"},{"id":"190814","messageId":"7vd36j8lc3.fsf@alter.siamese.dyndns.org","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-05T01:31:40Z","receivedAt":"2012-05-05T01:31:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Scott Chacon <schacon@gmail.com> writes:\n\n> Hey everyone,\n>\n> I just shipped a big update to the git-scm.com website,...\n\nThanks.  The Reference Manual area lists \"apply\" in a very funny place.\nIt should go together with \"diff\", whichever section you decide to put\n\"diff\" in.  As \"diff\" is listed in \"Basic Snapshotting\", and it will not\nbe able to achieve that without being able to apply its output back to the\nworking tree or to the index, I would suggest moving \"apply\" to the\nsection as well.\n\nI am fairly happy about the look of the new site except for a few things\n;-).\n\nIt seems that you are trying to advocate \"staging area\" as some sort of\nofficial term.  I think \"it is like a staging area\" is a good phrase to\nuse when answering \"what is the index?\", but I think repeating it million\ntimes without telling the casual readers what its official name is is\ncounterproductive.  Don't do that.  It will confuse these same people when\nthey start reading manuals.\n"},{"id":"190830","messageId":"4FA4EF85.2060104@pileofstuff.org","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2012-05-05T09:14:45Z","receivedAt":"2012-05-05T09:14:45Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"I had a poke round the site looking for trouble - here's what I found:\n\nI'm using Linux, but for some reason the front page offers me downloads\nfor Mac.  When I click on \"Mac GUIs\", I am taken to a sensible URL for\nMacs[1] but the button at the top says \"Only show GUIs for my own OS\n(Windows)\".  I'm not sure how the detection works, but I have Javascript\ndisabled and the following user agent string:\nMozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko)\nChrome/17.0.963.56 Safari/535.11\nAutomatically guessing the user's OS is a good way of reducing interface\ncomplexity, but for example the Firefox homepage[2] shows Windows, Linux\nand Mac OS buttons if it can't guess.  This probably also helps Google\nindex their site, as GoogleBot can follow links to all the OS-specific\ndownload pages.\n\nThe \"about\" section doesn't work in JS-disabled browsers - I always see\nthe \"branching and merging\" page no matter what I click on.  Again, this\nmeans GoogleBot most likely won't index the other pages.\n\nNot a bug, but a little tip - while investigating the issue on the\n\"about\" page, I noticed that all the links had href=\"#\".  You might want\nto consider using href=\"#some-unique-identifier\" so when you click round\nthe site with a JS-enabled browser and notice a \"#\" in the URL, you can\nidentify which click handler(s) failed.\n\nProbably another non-JS browser issue, although not one that will bother\nGoogle: the \"book\" section in the documentation page[3] has the first\n\"book cover\" block protruding way into the left column, with all its\ntext mirrored.\n\nNot a bug but a feature request: in the actual book pages, could you put\nthe prev/next links at the top as well as the bottom?  If I read through\nthe book, then come back a few weeks later looking for one of the pages,\nit's much quicker to click through links at the top without needing to\nscroll or move the mouse.\n\nThese bugs are relatively minor - the new site looks great overall.\n\n\t- Andrew\n\n[1] http://git-scm.com/download/gui/mac\n[2] http://www.mozilla.org/en-US/firefox/new/\n[3] http://git-scm.com/documentation\n"},{"id":"190842","messageId":"CAMP44s0rBm-6pWL7_BYw_Y3t9bPx5MxMmOsrMSCvd_PtvT+YVQ@mail.gmail.com","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-05T14:01:48Z","receivedAt":"2012-05-05T14:01:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nOn Sat, May 5, 2012 at 1:29 AM, Scott Chacon <schacon@gmail.com> wrote:\n> * We designed a new logo[1] - there are multiple variations available\n> for download on the site under the most permissive CC license for any\n> use.\n\nI don't like it. I don't see how it can possibly be related to git in\nany way. There are no plus and minus anywhere, nor green :)\n\nBut anyway, if you are going to use such a logo, perhaps you should\nchoose a less saturated red, or even green would be better, and use\nthe black version as the page favicon (like in github).\n\nSee how bad it looks in my browser:\nhttp://felipec.org/git-scm-screenshot.png\n\nAlso, the hugely saturated red on the rest of the page seems\noffsetting. A less saturated red often looks bad, but a less saturated\ngreen not so much.\n\nAnd probably rotate the logo it 180 degrees; it looks like development\nis going down?\n\nOther than that I think it's great :)\n\nThanks!\n\n-- \nFelipe Contreras\n"},{"id":"190844","messageId":"4C84FE6E927C4C04BB66EFC7122A61C8@PhilipOakley","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-05-05T14:36:30Z","receivedAt":"2012-05-05T14:36:30Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Scott Chacon\" <schacon@gmail.com>Sent: Saturday, May 05, 2012 12:29 \nAM\n> Hey everyone,\n>\n> I just shipped a big update to the git-scm.com website, incorporating\n> tons of feedback I've gotten on the site, especially from new users,\n> over the years.  I think it will help new users to Git find the right\n> installer and get up and running easier.  I have other ideas of things\n> to add to it in the future, but I think this is much better than the\n> site that has served us well for a few years now.\n>\n\nI liked the groupings of the commands on the doc/reference page \nhttp://git-scm.com/docs (plural).\nI felt they were reasonably grouped and relatively inviting to explore.\n\nThe visual cheatsheet looks interesting and informative, though wasn't what \nI was expecting from its title - perhaps \"interactive cheatsheet\"?\n[If they did a composite with all the cheats in cascade it'd make a good \nprintout]\n\nPhilip Oakley\n"},{"id":"190851","messageId":"CAMP44s17CYY-eoQKeEGDRQ5B+d_vni0GDpKcSjKRmoxjTFYwsg@mail.gmail.com","threadId":"30428","inReplyTo":"7vd36j8lc3.fsf@alter.siamese.dyndns.org","subject":"Re: git-scm.com refresh","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-05T16:47:22Z","receivedAt":"2012-05-05T16:47:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, May 5, 2012 at 3:31 AM, Junio C Hamano <gitster@pobox.com> wrote:\n\n> It seems that you are trying to advocate \"staging area\" as some sort of\n> official term.  I think \"it is like a staging area\" is a good phrase to\n> use when answering \"what is the index?\", but I think repeating it million\n> times without telling the casual readers what its official name is is\n> counterproductive.  Don't do that.  It will confuse these same people when\n> they start reading manuals.\n\nI think keeping the name 'index' is what is counter-productive. I\nthink most users don't even need to hear the term 'index' in order to\ninteract with the staging area in common operations, so they won't ask\n\"what is the index?\".\n\n-- \nFelipe Contreras\n"},{"id":"190865","messageId":"CAP2yMaJuGgowcdcySBa-qFNeaSCh8_LLv+d+g=WnGFpOf05vzw@mail.gmail.com","threadId":"30428","inReplyTo":"m38vh7qxs3.fsf@localhost.localdomain","subject":"Re: git-scm.com refresh","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2012-05-05T22:24:19Z","receivedAt":"2012-05-05T22:24:19Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Fri, May 4, 2012 at 5:26 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n>> version of any command: http://git-scm.com/docs/git-fsck/1.5.5\n>\n> That's very good.  Thank you very much for giving home to git manpages\n> online.\n>\n> It would be nice for those manpages to have the title of page to be\n> set appropriately, e.g. for http://git-scm.com/docs/git-bisect to have\n> \"git-bisect(1)\" or \"git-bisect(1) Manual Page\", or even perhaps\n> \"git-bisect(1) Manual Page - Find by binary search the change that\n> introduced a bug\" instead of just \"Git\".\n\nGood catch - I'm pushing that out in a minute.\n\n>> * We designed a new logo[1] - there are multiple variations available\n>> for download on the site under the most permissive CC license for any\n>> use.\n>\n> IMVHO it is too similar to Bazaar logo:\n>\n>  http://bazaar.canonical.com/bzricons/bazaar-logo.png\n>\n> I like the [---] git logo, but I guess it is a bit cryptic.\n>           [+++]\n>\n\nI was actually concerned with the same thing, but a) not that many\npeople are familiar with the Bzr logo and b) when I actually look at\nthe Bzr logo I don't really see that much in common.  It was done by\nsomeone totally unfamiliar with that logo and although I can still see\nsimilarities, I think it's a good, clean logo that would be easily\nrecognizable and much more versatile than what we have been using so I\ndecided to stick with it.\n\n\n>> Let me know if you run into anything or there are any features you\n>> would like to see.\n>\n> In my ancient 10-years old web browser (Mozilla 1.17.2, Linux) the new\n> layout is seriously broken (misaligned), and much less readable than\n> the old one (BTW. could you keep the old one, perhaps only the front\n> page, for comparison?).  Also the font size is too small.\n\nI have to assume that just about any modern site looks pretty awful to\nyou.  I honestly don't know what to do about this - I can't even test\nit really.  I am aware since the launch that a number of people have\nissues with JS being turned off, which I'm working on, but there's not\na lot I can do for browsers like that and I'm not sure what the point\nwould be anyhow.  People with browsers like that don't need anything\non this site as far as I can think of.  It targets people that don't\nknow Git and possibly don't know version control and are trying to\nfigure it out.\n\nI'll try to make it better, but it would be simpler if you could fix\nit and send me a pull request since I have no other way to see what\nyou're seeing with tech that out of date.\n\nScott\n"},{"id":"190866","messageId":"CAP2yMaJsDysqwwUga+fyWhUV-r78FoK7psY7howNBOCnsKLhvA@mail.gmail.com","threadId":"30428","inReplyTo":"7vd36j8lc3.fsf@alter.siamese.dyndns.org","subject":"Re: git-scm.com refresh","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2012-05-05T22:38:31Z","receivedAt":"2012-05-05T22:38:31Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Fri, May 4, 2012 at 6:31 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Thanks.  The Reference Manual area lists \"apply\" in a very funny place.\n> It should go together with \"diff\", whichever section you decide to put\n> \"diff\" in.  As \"diff\" is listed in \"Basic Snapshotting\", and it will not\n> be able to achieve that without being able to apply its output back to the\n> working tree or to the index, I would suggest moving \"apply\" to the\n> section as well.\n\nI have to disagree.  You are thinking of 'apply' from an internals\nperspective I have to assume, because I use 'diff' every single day\nfor all sorts of stuff (\"what is modified and unstaged?\", \"what is\nmodified and staged?\", \"what is different between these two branches?\"\netc) where I can't think of a single time I've ever used 'apply'.  In\nfact, even the times when I have needed to apply a patch generated\nfrom 'diff' I used 'patch -p1' because I know it better.  I, and most\npeople I would guess, almost never use 'diff' to generate patch files,\nwe use it to see what has changed before committing or things like\nthat - in general usage, it's more like an advanced 'status' honestly.\n\n> I am fairly happy about the look of the new site except for a few things\n> ;-).\n>\n> It seems that you are trying to advocate \"staging area\" as some sort of\n> official term.  I think \"it is like a staging area\" is a good phrase to\n> use when answering \"what is the index?\", but I think repeating it million\n> times without telling the casual readers what its official name is is\n> counterproductive.  Don't do that.  It will confuse these same people when\n> they start reading manuals.\n\nI'm not really trying to advocate it as much as using terminology that\nis already quite popular.  It's true that it's not what is used in the\nman pages, but neither is 'index' used consistently - there is 'cache'\ntoo, in addition to 'index' having two meanings - packfile and cache.\nI'm open to making things clearer, but I just don't think that\nchanging the terminology to something more technical and vague would\nbe overall less confusing to people.\n\nThat said, in most places I use phrases like 'Git has something called\nthe \"staging area\" or \"index\"' letting people know that there are\nmultiple phrases for it and what it's technical term tends to be.  So\nyour \"without telling the casual readers what its official name is\" is\ngenerally not true - I do try to do that too.\n\nScott\n"},{"id":"190868","messageId":"B09D9658-2BA5-4864-876D-39369B3C753B@gmail.com","threadId":"30428","inReplyTo":"m38vh7qxs3.fsf@localhost.localdomain","subject":"Re: git-scm.com refresh","fromName":"Josh Juran","fromEmail":"jjuran@gmail.com","sentAt":"2012-05-05T23:20:08Z","receivedAt":"2012-05-05T23:20:08Z","isPatch":false,"sender":{"key":"jjuran@gmail.com","avatar":null},"body":"On May 4, 2012, at 5:26 PM, Jakub Narebski wrote:\n\n> Scott Chacon <schacon@gmail.com> writes:\n>\n>> * We designed a new logo[1] - there are multiple variations available\n>> for download on the site under the most permissive CC license for any\n>> use.\n>\n> IMVHO it is too similar to Bazaar logo:\n>\n>   http://bazaar.canonical.com/bzricons/bazaar-logo.png\n\nThat's nothing compared to the similarity between the Bazaar logo and  \nthe MacCVS Pro logo:\n\nhttp://www.maccvs.org/images/roadsign_small.gif\n\nJosh\n"},{"id":"190869","messageId":"4FA5C11B.6020701@gmail.com","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-05-06T00:08:59Z","receivedAt":"2012-05-06T00:08:59Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 5/4/2012 6:29 PM, Scott Chacon wrote:\n>\n> I just shipped a big update to the git-scm.com website\n>\nI'll miss Torvald the Troll (http://torvald.gjovaag.com/)showing the \ntrees of thor's woods (tor's wald) who's boss.  :(\n\n> * There is now permanent man page hosting here\n\nThanks for rescuing the man!  I suppose you also had help from the ents. \n  Thanks to them too.  :)\n\n> Let me know if you run into anything or there are any features you\n> would like to see.\n\nThe new homepage looks too slick.  The hacky look of the old one was \nmore in keeping with cli git.  This is git.git, not github.  ;)\n\nv/r,\nneal\n"},{"id":"190870","messageId":"7vwr4q6qbh.fsf@alter.siamese.dyndns.org","threadId":"30428","inReplyTo":"CAP2yMaJsDysqwwUga+fyWhUV-r78FoK7psY7howNBOCnsKLhvA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-06T01:39:14Z","receivedAt":"2012-05-06T01:39:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Scott Chacon <schacon@gmail.com> writes:\n\n>> As \"diff\" is listed in \"Basic Snapshotting\", and it will not\n>> be able to achieve that without being able to apply its output back to the\n>> working tree or to the index, I would suggest moving \"apply\" to the\n>> section as well.\n>\n> I have to disagree.  You are thinking of 'apply' from an internals\n> perspective I have to assume, because I use 'diff' every single day\n> for all sorts of stuff (\"what is modified and unstaged?\", \"what is\n> modified and staged?\", \"what is different between these two branches?\"\n> etc) ...\n\nThe other day when I was surfing the 'net, I found a blog that was\ncomplaining about Git UI.  Some of the things were worth listening to, but\nthere was one item I really had to scratch my head where the misconception\nbehind the complaint came from.  I am typing from memory without bothering\nto go back to the site to quote, but the complaint essentially was:\n\n        Getting a patch is easy with \"git diff\", but to apply it you need\n        to make it an email and feed it to \"git am\"???  That's crazy.\n\nOf course it *is* crazy, if that were the case. I was wondering why the\nobvious \"patch\" (or \"git apply\") did not get into the mind of the author,\nand I think I now know why.\n\nIf the owner of the site that people call \"git's home page\" does not care\nabout those who take diffs and apply them as patches, and thinks \"git\napply\" as a mere implementation detail of \"git am\", it is understandable\nthat such a misconception is spread widely to harm users without getting\ncorrected. Who knows other Git fanboys are spreading misinformation in a\nsimilar way. Sigh...\n\n> ... where I can't think of a single time I've ever used 'apply'.  In\n> fact, even the times when I have needed to apply a patch generated\n> from 'diff' I used 'patch -p1' because I know it better.\n\nAs you are supposed to be one of the top-level Git Teachers, I wish you\nknew better.  Here is a free Git lesson.  Consider \"git apply\" as\n\n    a better version of \"patch\" that knows how to work better with Git by\n    understanding rename and binary patches, and allows them to be applied\n    to the working tree and the index (the latter is most useful when the\n    patch contains new files)\n\nand teach it as such.\n\n\"diff\" pairs with \"apply\", and \"format-patch\" pairs with \"am\".\n\nI wouldn't mind adding \"git patch\" as a built-in synonym/alias for \"git\napply\", if you think that would make the above pairing more obvious.  Many\ncomputer users know what \"patch\" does already even they have never used\nany SCM.\n\n[Footnote]\n"},{"id":"190871","messageId":"CAMP44s28Xy4PB-k33RYU=W2Wa+SLs7GDkhr=DohUP_hqr5ur9Q@mail.gmail.com","threadId":"30428","inReplyTo":"7vwr4q6qbh.fsf@alter.siamese.dyndns.org","subject":"Re: git-scm.com refresh","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-06T02:31:35Z","receivedAt":"2012-05-06T02:31:35Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, May 6, 2012 at 3:39 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Scott Chacon <schacon@gmail.com> writes:\n>\n>>> As \"diff\" is listed in \"Basic Snapshotting\", and it will not\n>>> be able to achieve that without being able to apply its output back to the\n>>> working tree or to the index, I would suggest moving \"apply\" to the\n>>> section as well.\n>>\n>> I have to disagree.  You are thinking of 'apply' from an internals\n>> perspective I have to assume, because I use 'diff' every single day\n>> for all sorts of stuff (\"what is modified and unstaged?\", \"what is\n>> modified and staged?\", \"what is different between these two branches?\"\n>> etc) ...\n>\n> The other day when I was surfing the 'net, I found a blog that was\n> complaining about Git UI.  Some of the things were worth listening to, but\n> there was one item I really had to scratch my head where the misconception\n> behind the complaint came from.  I am typing from memory without bothering\n> to go back to the site to quote, but the complaint essentially was:\n>\n>        Getting a patch is easy with \"git diff\", but to apply it you need\n>        to make it an email and feed it to \"git am\"???  That's crazy.\n>\n> Of course it *is* crazy, if that were the case. I was wondering why the\n> obvious \"patch\" (or \"git apply\") did not get into the mind of the author,\n> and I think I now know why.\n>\n> If the owner of the site that people call \"git's home page\" does not care\n> about those who take diffs and apply them as patches, and thinks \"git\n> apply\" as a mere implementation detail of \"git am\", it is understandable\n> that such a misconception is spread widely to harm users without getting\n> corrected. Who knows other Git fanboys are spreading misinformation in a\n> similar way. Sigh...\n\nSo you think moving \"git apply\" to another section there is going to\nfix the problem? And what is the problem? That some random guy in a\nblog post thinks it's crazy to use 'git format-patch' and 'git am'? I\ndon't think that's a problem worth worrying about, and I don't think\nit's crazy.\n\nWho cares if people don't know about \"git apply\"? I too have used it\nvery rarely, and almost every time I gave up. It's not really useful\nbecause if there are conflicts (and there usually are), the thing just\nfails, and 'git apply --reject' (horrible name BTW; apply and reject a\npatch?) is too cumbersome. It's much easier to just avoid it.\n\n>> ... where I can't think of a single time I've ever used 'apply'.  In\n>> fact, even the times when I have needed to apply a patch generated\n>> from 'diff' I used 'patch -p1' because I know it better.\n>\n> As you are supposed to be one of the top-level Git Teachers, I wish you\n> knew better.  Here is a free Git lesson.  Consider \"git apply\" as\n>\n>    a better version of \"patch\" that knows how to work better with Git by\n>    understanding rename and binary patches, and allows them to be applied\n>    to the working tree and the index (the latter is most useful when the\n>    patch contains new files)\n>\n> and teach it as such.\n\nIt's still basically useless.\n\n> \"diff\" pairs with \"apply\", and \"format-patch\" pairs with \"am\".\n\nA contributor uses 'format-patch' often, a maintainer uses 'am' often,\nbut who uses 'apply'? Nobody. Who uses 'diff'? Everybody.\n\n'git diff' is *essential* to see what's going on with the staging\narea, and the working directory.\n\nWhen do you actually *need* 'git apply'? Never; you can always achieve\nthe same in different ways probably much easier.\n\n> I wouldn't mind adding \"git patch\" as a built-in synonym/alias for \"git\n> apply\", if you think that would make the above pairing more obvious.  Many\n> computer users know what \"patch\" does already even they have never used\n> any SCM.\n\n'git patch' would certainly make more sense, but even more would be to\nmake it actually usable so mergetool could be used in case of\nconflicts, or even just having the typical conflict markers.\n\nBut even with all that, it still wouldn't be as essential as 'git diff'.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"190872","messageId":"CAP2yMaJwT6=hEwt+v2OHB8yDdXQzV2P1kAimkN_a6GHtqkRJkQ@mail.gmail.com","threadId":"30428","inReplyTo":"7vwr4q6qbh.fsf@alter.siamese.dyndns.org","subject":"Re: git-scm.com refresh","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2012-05-06T03:51:07Z","receivedAt":"2012-05-06T03:51:07Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"On Sat, May 5, 2012 at 6:39 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Scott Chacon <schacon@gmail.com> writes:\n>\n>>> As \"diff\" is listed in \"Basic Snapshotting\", and it will not\n>>> be able to achieve that without being able to apply its output back to the\n>>> working tree or to the index, I would suggest moving \"apply\" to the\n>>> section as well.\n>>\n>> I have to disagree.  You are thinking of 'apply' from an internals\n>> perspective I have to assume, because I use 'diff' every single day\n>> for all sorts of stuff (\"what is modified and unstaged?\", \"what is\n>> modified and staged?\", \"what is different between these two branches?\"\n>> etc) ...\n>\n> The other day when I was surfing the 'net, I found a blog that was\n> complaining about Git UI.  Some of the things were worth listening to, but\n> there was one item I really had to scratch my head where the misconception\n> behind the complaint came from.  I am typing from memory without bothering\n> to go back to the site to quote, but the complaint essentially was:\n>\n>        Getting a patch is easy with \"git diff\", but to apply it you need\n>        to make it an email and feed it to \"git am\"???  That's crazy.\n>\n> Of course it *is* crazy, if that were the case. I was wondering why the\n> obvious \"patch\" (or \"git apply\") did not get into the mind of the author,\n> and I think I now know why.\n\nYou think he doesn't know about 'git apply' because I'm not listing it\nunder Basic Snapshotting in the site I put live yesterday?  Or because\nI'm not teaching that?  That makes no sense, I don't understand why\nyou think I'm to blame for this guy not knowing that.  If anything,\nthis new grouping will help that, since it clearly puts 'apply' under\na section explicitly labeled 'Patching'.  It doesn't belong in \"Basic\nSnapshotting\" because that's not at all what it's used for and it\ndoesn't make sense to put 'diff' under 'Patching' because that's not\nit's primary use case - it is mainly used to see what differences are\nin various cases, not to create patch files.\n\n> If the owner of the site that people call \"git's home page\" does not care\n> about those who take diffs and apply them as patches, and thinks \"git\n> apply\" as a mere implementation detail of \"git am\", it is understandable\n> that such a misconception is spread widely to harm users without getting\n> corrected. Who knows other Git fanboys are spreading misinformation in a\n> similar way. Sigh...\n\nFor one, it's not that I don't care, it's that I don't think that how\nyou're considering the problem set here is common.  I'm trying to make\nGit a little bit easier to approach by grouping many of the commands\ninto groups by the problems they are primarily used to address.  If\nyou can argue that 'diff' is *primarily* used to create patch files\nfor 'apply' to consume, then I would be happy to argue that, but\nthat's not what you're saying.  You're ignoring my argument that I\nbelieve that 'diff' is used primarily for another use case and that\nthat use case is closer to 'status' then to 'apply'.\n\n>> ... where I can't think of a single time I've ever used 'apply'.  In\n>> fact, even the times when I have needed to apply a patch generated\n>> from 'diff' I used 'patch -p1' because I know it better.\n>\n> As you are supposed to be one of the top-level Git Teachers, I wish you\n> knew better.  Here is a free Git lesson.  Consider \"git apply\" as\n>\n>    a better version of \"patch\" that knows how to work better with Git by\n>    understanding rename and binary patches, and allows them to be applied\n>    to the working tree and the index (the latter is most useful when the\n>    patch contains new files)\n>\n> and teach it as such.\n\nThere is absolutely no reason to be this condescending.  You can read\na similar description of 'apply' in the context of applying patches\nproduced by 'diff' in my book which is CC licensed and now makes up a\nlarge part of the git-scm.com site here:\n\nhttp://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project#Applying-Patches-from-E-mail\n\nIt is also one of the top results when searching for 'apply' on the\nsite and it is cross-linked from the git-apply manpage in the sidebar.\n It's difficult for me to see how this can be made more clear by me on\nthis site.\n\n>\n> \"diff\" pairs with \"apply\", and \"format-patch\" pairs with \"am\".\n>\n\nIf you read on through the next paragraph in that book you will see\nthis covered as well, as a slightly different use case where the\ncontributor used 'format-patch' instead.\n\nOr, if you wish, you can read it in German, Japanese, French, Dutch,\nRussian, Chinese or Spanish - the languages that have fully translated\nmy book and are also available on the site.  It's difficult to see why\nyou think I'm making this perceived issue worse.\n\n> I wouldn't mind adding \"git patch\" as a built-in synonym/alias for \"git\n> apply\", if you think that would make the above pairing more obvious.  Many\n> computer users know what \"patch\" does already even they have never used\n> any SCM.\n\nI don't think this is a good idea at all and I've never advocated\nthis.  If people know what GNU 'patch' is they can use that, if people\nglance at the new git-scm.com site they should be able to easily see\n'git apply'  listed under other patch-y workflow tools.  What would be\nfar easier would be for me to simply list 'diff' under both sections,\nsince what we're really struggling with is the multiple use cases of\nthe 'diff' command.  I think I'll just do that, OK?\n\nScott\n"},{"id":"190875","messageId":"4FA607C2.6030906@gmail.com","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-05-06T05:10:26Z","receivedAt":"2012-05-06T05:10:26Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 5/4/2012 6:29 PM, Scott Chacon wrote:\n>\n> I just shipped a big update to the git-scm.com website...\n>\nThanks for the cool website, old and new!  :)\n\n> * There is now permanent man page hosting here, for example:\n> http://git-scm.com/docs/git-fsck.  You can also reference any older\n> version of any command: http://git-scm.com/docs/git-fsck/1.5.5\n>\nIMO, I think the reference manual before the kernel.org crash was the \nbest.  Back then, you first got a list of all the versions and you \npicked your version.  If I'm on version x I want to click on version x \none time for the entire refman, not for every manpage.\n\nI prefer the git.git make doc version of the html.  If you could have a \n'classic' view of the reference manual that would be great.  I'm not an \nexpert on the make doc technologies, but if your version is harder to \nget working then a classic view would enable you to quickly and reliably \npublish updates while ironing out the enhanced version.\n\nAlso, the new format has *way* too much whitespace on the sides for the \nmanpages.  (Progit also has too much whitespace -- was it like that \nbefore?)  The manpages are long enough without double column width in a \nsingle column.  ;)  The related topics is interesting.  I think this \nhybrid reference manual format should be called 'enhanced' or something. \n  I think its important to keep the official git reference manual \nclearly distinguished from supplemental material because some of the \nsupplements are not correct (ie, [a]progit merge=ours).  I think the new \nhybrid format disguised as the reference manual will cause the newsgroup \nto get alot of questions about supplemental material confused with the \nreference manual pages.  They probably already spend too much time \ncorrecting my bum scoop posts as it is.  ;)\n\nI'm not a website expert, but an option to pick a stylesheet that has a \nmain theme color of blue, green, etc., as opposed to red-orange that \nwould a big plus in keeping with the open source concept.  I'm not a \nvisual brain scientist, but I think my aversion to staring at a \nred-orange website all the time has something to do with why walls are \nnot normally painted red-orange either.  ;)\n\n> * There are still a few asciidoc parsing issues that we're working on\n> - if you find anything that's weird please report it at our issue\n> tracker: https://github.com/github/gitscm-next/issues\n>\ngit-rebase manpage is pretty hosed.  (when i tried to report on github \nit wanted me to signup.)\n\nFootnotes:\na.  http://git-scm.com/book/en/Customizing-Git-Git-Attributes,\nhttp://comments.gmane.org/gmane.comp.version-control.git/192798\n\nv/r,\nneal\n"},{"id":"190884","messageId":"C0239E9A908644EAB06A52AE4A90F401@PhilipOakley","threadId":"30428","inReplyTo":"7vwr4q6qbh.fsf@alter.siamese.dyndns.org","subject":"Re: git-scm.com refresh","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-05-06T08:33:10Z","receivedAt":"2012-05-06T08:33:10Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" <gitster@pobox.com> Sent: Sunday, May 06, 2012 2:39\nAM\n > Scott Chacon <schacon@gmail.com> writes:\n>\n>>> As \"diff\" is listed in \"Basic Snapshotting\", and it will not\n>>> be able to achieve that without being able to apply its output back to\n>>> the\n>>> working tree or to the index, I would suggest moving \"apply\" to the\n>>> section as well.\n>>\n>> I have to disagree.  You are thinking of 'apply' from an internals\n>> perspective I have to assume, because I use 'diff' every single day\n>> for all sorts of stuff (\"what is modified and unstaged?\", \"what is\n>> modified and staged?\", \"what is different between these two branches?\"\n>> etc) ...\n>\n> The other day when I was surfing the 'net, I found a blog that was\n> complaining about Git UI.  Some of the things were worth listening to, but\n> there was one item I really had to scratch my head where the misconception\n> behind the complaint came from.  I am typing from memory without bothering\n> to go back to the site to quote, but the complaint essentially was:\n>\n>        Getting a patch is easy with \"git diff\", but to apply it you need\n>        to make it an email and feed it to \"git am\"???  That's crazy.\n>\n<snip>\n\n> \"diff\" pairs with \"apply\", and \"format-patch\" pairs with \"am\".\n>\n> I wouldn't mind adding \"git patch\" as a built-in synonym/alias for \"git\n> apply\", if you think that would make the above pairing more obvious.  Many\n> computer users know what \"patch\" does already even they have never used\n> any SCM.\n>\n\nPart of the problem is that the `git diff` man page [1] doesn't actively\ntell the user that its result will be in a patch format, and that such a\npatch can be `apply`ed. There are only 5 uses of 'apply' buried in the body\ntext, never as a command, as if they are special cases. There is a section\non the -p option, again it feels like it is a special case.\n\nThe \"--patch\" option in [1] is corrupted(?) relative to my desktop in that \nit\nmisses the \"(This is the default.)\" ending (which most readers skip over \nwhen\nspeed reading).\n\nThe normal case of `git diff` for most users is simply as an extended 'what\nchanged' git status.\n\nThe `git apply` page [2] does say its about a diff:\n    \"DESCRIPTION - Reads the supplied diff output (i.e. \"a patch\") and\n    applies it to files.\"\nso it reads ok in reverse.\n\nPerhaps for `git diff` man page\n    NAME - git-diff - Show changes/, usually as a patch,/ between commits,\n    commit and working tree, etc.\n\nThen\n    DESCRIPTION - Show changes ...two files on disk.\n     /You can implement a diff patch by using git-apply(1)./\n\nThe main point is that the new user is probably unaware of many of the\nconventions others take for granted. This gives them 'a clue' about `apply`.\n\nPhilip\n\n[1] http://git-scm.com/docs/git-diff\n[2] http://git-scm.com/docs/git-apply.html\n"},{"id":"190894","messageId":"vpqd36hlgf1.fsf@bauges.imag.fr","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-05-06T11:04:02Z","receivedAt":"2012-05-06T11:04:02Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Scott Chacon <schacon@gmail.com> writes:\n\n> * There is now permanent man page hosting here, for example:\n> http://git-scm.com/docs/git-fsck.  You can also reference any older\n> version of any command: http://git-scm.com/docs/git-fsck/1.5.5\n\nGreat.\n\nCould somebody with kernel.org access set up redirects from\nhttp://www.kernel.org/pub/software/scm/git/docs/* to these pages? There\nare still tons of links pointing to kernel.org's 404 errors ...\n\nSome time ago, you mentionned some plans to host a wiki on git-scm.com,\nis it still the case? I noticed that the kernel.org wiki was back since\na few days, so the question is different now.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"190912","messageId":"CAP2yMaKd79Kj6ixtWO8g_UZqagrpcWtKkbk5j5+-aTmKVr2_jQ@mail.gmail.com","threadId":"30428","inReplyTo":"vpqd36hlgf1.fsf@bauges.imag.fr","subject":"Re: git-scm.com refresh","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2012-05-06T13:36:49Z","receivedAt":"2012-05-06T13:36:49Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Sun, May 6, 2012 at 4:04 AM, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n> Great.\n>\n> Could somebody with kernel.org access set up redirects from\n> http://www.kernel.org/pub/software/scm/git/docs/* to these pages? There\n> are still tons of links pointing to kernel.org's 404 errors ...\n>\n> Some time ago, you mentionned some plans to host a wiki on git-scm.com,\n> is it still the case? I noticed that the kernel.org wiki was back since\n> a few days, so the question is different now.\n\nI am still planning on doing this.  Since it took them several months\nto get back and as you point out, while they're down links go bad all\nover the place, I am planning on owning the wiki so we can have more\ncontrol over it.  I also want to make it easier to contribute to it\nand have it be Git backed.  This is a project on my to-do list.\n\nScott\n"},{"id":"190961","messageId":"CAP8UFD0SX30rBV0jAvogLeZgS_0_WDMYTBhkkC4T5_17PO-MxA@mail.gmail.com","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2012-05-07T04:18:10Z","receivedAt":"2012-05-07T04:18:10Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Scott,\n\nOn Sat, May 5, 2012 at 1:29 AM, Scott Chacon <schacon@gmail.com> wrote:\n> Hey everyone,\n>\n> I just shipped a big update to the git-scm.com website, incorporating\n> tons of feedback I've gotten on the site, especially from new users,\n> over the years.  I think it will help new users to Git find the right\n> installer and get up and running easier.  I have other ideas of things\n> to add to it in the future, but I think this is much better than the\n> site that has served us well for a few years now.\n>\n> Some other interesting things to note:\n>\n> * There is now permanent man page hosting here, for example:\n> http://git-scm.com/docs/git-fsck.  You can also reference any older\n> version of any command: http://git-scm.com/docs/git-fsck/1.5.5\n\nGreat!\n\n> * We designed a new logo[1] - there are multiple variations available\n> for download on the site under the most permissive CC license for any\n> use.\n\nI prefer the old one.\n\n> * The Pro Git book (and all of it's translations) has been directly\n> incorporated into the site and has better permalinks and section\n> anchors.  progit.org will soon be redirecting to git-scm.com.\n\nIt's good to have it integrated but on the other hand I don't like the\nboxes on the left side of each page about the book.\nIt just looks to me like an (annoying) ad.\n\n> * Matthew McCullough has started a video series[2] for newbies and\n> will continue to do more developer and intermediate type videos as\n> well.\n\nNice.\n\n> * There are still a few asciidoc parsing issues that we're working on\n> - if you find anything that's weird please report it at our issue\n> tracker: https://github.com/github/gitscm-next/issues\n>\n> Let me know if you run into anything or there are any features you\n> would like to see.\n\nI would like the page about the git authors to be back.\n\nThanks,\nChristian.\n"},{"id":"191002","messageId":"4FA7E582.9090709@gmail.com","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2012-05-07T15:08:50Z","receivedAt":"2012-05-07T15:08:50Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"On 05/04/2012 07:29 PM, Scott Chacon wrote:\n> Hey everyone,\n>\n> I just shipped a big update to the git-scm.com website, incorporating\n> tons of feedback I've gotten on the site, especially from new users,\n> over the years.  I think it will help new users to Git find the right\n> installer and get up and running easier.  I have other ideas of things\n> to add to it in the future, but I think this is much better than the\n> site that has served us well for a few years now.\n\n[...]\n\nI was looking over the updated website and what follows are my initial \nimpressions:\n\n1) I like the old logo much better.\n\n2) I notice that GitHub is NOT listed as a company or project using git \non the main page. What SCM does GitHub use? :-O\n\n3) On the About -> Small and Fast Page: you show a comparison to Git and \nGit* for the clone operation but there is no explanation of how Git and \nGit* differ.\n\n4) It's 2 clicks to get to a category view of the man pages: I think \nthat's 1 too many.\n\n5) I would like to see a page that lists all of the documentation in the \ncore distribution in one place. A good place for this would be somewhere \nnear the top of the category view page.\n\n6) The documentation pages should let the user decide with one click \nwhich version of the documentation set they wish to view instead of \nhaving to do it for every page.\n\n7) A help topic on the category view page about determining which \nversion of the documentation matches the user's installed version of Git \nwould be useful.\n"},{"id":"191009","messageId":"7vipg77wg1.fsf@alter.siamese.dyndns.org","threadId":"30428","inReplyTo":"C0239E9A908644EAB06A52AE4A90F401@PhilipOakley","subject":"Re: git-scm.com refresh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-07T17:06:06Z","receivedAt":"2012-05-07T17:06:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" <philipoakley@iee.org> writes:\n\n> From: \"Junio C Hamano\" <gitster@pobox.com> Sent: Sunday, May 06, 2012 2:39\n>\n>> \"diff\" pairs with \"apply\", and \"format-patch\" pairs with \"am\".\n>>\n>> I wouldn't mind adding \"git patch\" as a built-in synonym/alias for \"git\n>> apply\", if you think that would make the above pairing more obvious.  Many\n>> computer users know what \"patch\" does already even they have never used\n>> any SCM.\n>\n> Part of the problem is that the `git diff` man page [1] doesn't actively\n> tell the user that its result will be in a patch format, and that such a\n> patch can be `apply`ed. There are only 5 uses of 'apply' buried in the body\n> text, never as a command, as if they are special cases. There is a section\n> on the -p option, again it feels like it is a special case.\n\nSounds like you spotted a good set of places in the documentation that\nneed to be updated.\n\n> The normal case of `git diff` for most users is simply as an extended 'what\n> changed' git status.\n\nI think that use of \"diff\" is listed in \"Inspection and Comparison\"\nsection, and I fully agree and is happy to see \"diff\" there as well.  Of\ncourse, I wouldn't suggest \"apply\" to go next to that use of \"diff\".\n\nBut what I have been discussing was the use of \"diff\" in the \"Basic\nSnapshotting\" section.  I actually very often use \"diff\" paired with\n\"apply\" for my own work, not when working to integrate others' work.  \n\nAlso I do not think anybody would use \"apply\" to accept patches (that is\nwhat \"am\" is for), so listing it in \"Email\" section is doubly wrong.  If\nfor some reason the command Reference does not want to have \"apply\" next\nto \"diff\" listed in \"Basic Snapshotting\", I do not think there is any\ncategory on that page for the command to belong to.\n\nThe above two were the primary things that triggered my reaction.\n\nWhen reshaping a multi-commit series, \"git diff $rev1 $rev2 >P.diff\"\nfollowed by \"git apply <P.diff\" (either with or without editing P.diff in\nbetween) is sometimes a more versatile and even more natural solution than\nrepeated use of \"rebase -i\" is, depending on what kind of reshaping\nI want to do.\n\nFor example, after an exploratory development session, I often end up\nwith something like this (time flows from top to bottom):\n\n\tupdate A\n        update D\n        refactor and modify B\n\tupdate E\n        refactor and modify C\n\nand then I realize that the refactoring I needed to give to B and C are\nthe similar kind, and is better done as a single step early in the\nseries.  This will involve splitting two \"refactor and modify\" commits\ninto four, reorder and squash in different combinations.  It often is the\nmost convenient to\n\n\tgit checkout \":/update A\"\n        git diff \":/update D\" \":/refactor and modify B\" | git apply\n        git add -p ;# only keep the 'refactor' bit\n        git checkout . ;# and lose the 'modify' part\n        git diff \":/update E\" \":/refactor and modify C\" | git apply\n        git add -p ;# only keep the 'refactor' bit\n        git checkout . ;# and lose the 'modify' part\n\tgit commit -c ':/refactor and modify C'\n\nwhen rebuilding 'refactor B and C' on top of 'update A'.  Of course this\ndoes not have to be \"rebase\" but picking only part of good infrastructure\nchange from totally unrelated branch.  A concrete example is the recent\nindex-v4 series started by a commit that borrowed a small part of older\njc/split-blob series to refactor a varint API, and the diff to apply pipe\nwith editing (because the API needed to be cleaned up for the index-v4\nwork) was how a part of change was extracted from older branch (later the\njc/split-blob was rewritten to base it on the updated varint API that\nwas cleaned up for the index-v4 series).\n\nIn such a workflow, the use of \"diff\" is very much \"Basic snapshotting\"\n(which is the category head I was referring to).  It is used as a mechaism\nto take a snapshot, and not as a measure for \"Inspection and Comparison\".\n\nAnd the way to replay that basic snapshot to the working tree is \"git\napply\".  Without the matching pair, \"git diff\" does not serve well as a\n\"Basic snapshotting\" feature.\n\nI do not think Scott is ignorant of or unsympathetic to such a use case\n(after all, he mentioned use of GNU patch on \"git diff\" output, so he must\nuse \"take a diff to stash away some change, then replay it to the working\ntree\" workflow, even if much less often than I do.  Perhaps he personally\nuses it not so often and its usefulness escaped him).\n\nIt is a different topic if it makes sense to enhance \"rebase -i\" to\nsupport \"split two, shuffle and squash in a different way\".  I do not\nthink of a good UI for such an operation offhand.\n"},{"id":"191010","messageId":"CACBZZX5uzvJF4duCZCmbJOSKYK1gZmHmewqxkmwAP3R2ng3VYw@mail.gmail.com","threadId":"30428","inReplyTo":"CAP8UFD0SX30rBV0jAvogLeZgS_0_WDMYTBhkkC4T5_17PO-MxA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-05-07T17:08:49Z","receivedAt":"2012-05-07T17:08:49Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, May 7, 2012 at 6:18 AM, Christian Couder\n<christian.couder@gmail.com> wrote:\n> I would like the page about the git authors to be back.\n\nI'd also like that back, it was the best done author page in any\nproject I've seen because it was automatically generated and regularly\nupdated.\n"},{"id":"191034","messageId":"vpqfwbbitxn.fsf@bauges.imag.fr","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-05-07T21:04:52Z","receivedAt":"2012-05-07T21:04:52Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Scott Chacon <schacon@gmail.com> writes:\n\n> Let me know if you run into anything or there are any features you\n> would like to see.\n\nOn http://git-scm.com/community one can see how to post and how to read\nthe archives of the mailing-list, but not how to subscribe. I guess you\nneed to add a link to http://vger.kernel.org/vger-lists.html#git\n\nTyping \"git@vger.kernel.org\" in the search box gives no result. Probably\nthe search box should suggest searching an external search engine (e.g.\ngoogle, restricted to git-scm.org)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"191083","messageId":"loom.20120508T134617-647@post.gmane.org","threadId":"30428","inReplyTo":"CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com","subject":"Re: git-scm.com refresh","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2012-05-08T12:29:11Z","receivedAt":"2012-05-08T12:29:11Z","isPatch":false,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"Scott Chacon <schacon <at> gmail.com> writes:\n\n> \n> Hey everyone,\n> \n> I just shipped a big update to the git-scm.com website, incorporating\n> tons of feedback I've gotten on the site, especially from new users,\n> over the years.  I think it will help new users to Git find the right\n> installer and get up and running easier.  I have other ideas of things\n> to add to it in the future, but I think this is much better than the\n> site that has served us well for a few years now.\n> \n> Some other interesting things to note:\n> \n> * There is now permanent man page hosting here, for example:\n> http://git-scm.com/docs/git-fsck.  You can also reference any older\n> version of any command: http://git-scm.com/docs/git-fsck/1.5.5\n>\n\nSome pages are not displayed correctly:\nhttp://git-scm.com/docs/git-rebase for instance gets corrupted at some point.\n\n> * We designed a new logo[1] - there are multiple variations available\n> for download on the site under the most permissive CC license for any\n> use.\n> \n\nFWIW I also miss the + and - in the logo but I think I will survive :)\n\nThanks,\n   Antonio Ospite\n   http://ao2.it\n"},{"id":"191119","messageId":"7vlil2wr8k.fsf@alter.siamese.dyndns.org","threadId":"30428","inReplyTo":"7vipg77wg1.fsf@alter.siamese.dyndns.org","subject":"Re: git-scm.com refresh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-08T16:51:39Z","receivedAt":"2012-05-08T16:51:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> But what I have been discussing was the use of \"diff\" in the \"Basic\n> Snapshotting\" section.  I actually very often use \"diff\" paired with\n> \"apply\" for my own work, not when working to integrate others' work.  \n>\n> Also I do not think anybody would use \"apply\" to accept patches (that is\n> what \"am\" is for), so listing it in \"Email\" section is doubly wrong.  If\n> for some reason the command Reference does not want to have \"apply\" next\n> to \"diff\" listed in \"Basic Snapshotting\", I do not think there is any\n> category on that page for the command to belong to.\n>\n> The above two were the primary things that triggered my reaction.\n>\n> When reshaping a multi-commit series, \"git diff $rev1 $rev2 >P.diff\"\n> followed by \"git apply <P.diff\" (either with or without editing P.diff in\n> between) is sometimes a more versatile and even more natural solution than\n> repeated use of \"rebase -i\" is, depending on what kind of reshaping\n> I want to do.\n>\n> For example,...  Of course this\n> does not have to be \"rebase\" but picking only part of good infrastructure\n> change from totally unrelated branch.  A concrete example is ...\n\nI encountered another example yesterday after sending the above message\n[*1*].  I was fixing one small bug, and had a commit that updates code and\nadds a test vector.  It is a single commit on top of the current branch\ntip, which allegedly as a buggy code.\n\nThen I wanted to double check that the bug really existed before the fix.\n\n\tgit checkout HEAD^\n        git show @{-1} t/ | git apply\n        make test\n\nThe above gave me the pristine state plus only new tests to let me see the\nold code was indeed buggy.\n\nI also hit another example use case yesterday.\n\nA series was posted that was a fix that should go to \"maint\" but the\npathces were based on \"master\".  The usual \"git am -s3c\" on \"maint\" didn't\nexactly grok the series, as there were semantic conflicts (a new field was\nadded between \"maint\" and \"master\" to the structure the patch touches to\nadd yet another field).  So here is what I had to do:\n\n\tgit checkout -b jk/status-porcelain-z-b master\n        git am -s ./+mbox\n        git checkout -b jk/maint-status-porcelain-z-b\n        git rebase --onto maint master\n        ... fix conflicts, resolving semantic conflicts along the way\n\n\tgit checkout -B jk/status-porcelain-z-b master\n        ... at this point, jk/status-porcelain-z-b@{1} is what the series\n        ... applied to 'master' as the poster intended.\n        git merge jk/maint-status-porcelain-z-b\n        ... conflicts, which is more or less a squashed version of the\n        ... mess I dealt with when I rebased the original to maint\n        ... rerere will replay the mechanical part.\n\t... look at the conflict in \"git diff\" (no other\n\t... arguments) and making sure that it mostly makes sense.\n\tgit add -u\n        git diff\n        git diff HEAD\n        ... but the semantic conflict part is still missing, which\n        ... can be eyeballed like this.\n        git diff -R jk/status-porcelain-z-b@{1}\n        ... then transport the remaining changes.\n        git diff -R jk/status-porcelain-z-b@{1} | git apply --index\n\t... and then double check the result\n        git diff HEAD\n\nAnd I had exactly the same use case today for another series.\n\nIt turns out that \"nobody uses apply while accepting patches\" is not quite\ntrue.  I do use \"apply\" while accepting patches.  But I do not use it on\n\"format-patch\" output.  That is what \"am\" is for.\n\nIn any case, the latter part of the write-up above was done primarily\nbecause I thought it would be illustrative for others who need to flip\ncommits (whether it comes in patch form, or you develop your own) between\nmultiple code bases.  As people say, just my two cents ;-)\n\n\n[Footnote]\n \n*1* I admit that I use \"apply\" so often that I do not have to think when\nusing it, and I realize use cases of it only during the course of the\nusual work day, not during a theoretical \"I do not think anybody uses 'git\napply' on 'git diff' output\" discussion.\n"},{"id":"191138","messageId":"m262c6h8ft.fsf@igel.home","threadId":"30428","inReplyTo":"7vlil2wr8k.fsf@alter.siamese.dyndns.org","subject":"Re: git-scm.com refresh","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-05-08T17:46:46Z","receivedAt":"2012-05-08T17:46:46Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I encountered another example yesterday after sending the above message\n> [*1*].  I was fixing one small bug, and had a commit that updates code and\n> adds a test vector.  It is a single commit on top of the current branch\n> tip, which allegedly as a buggy code.\n>\n> Then I wanted to double check that the bug really existed before the fix.\n>\n> \tgit checkout HEAD^\n>         git show @{-1} t/ | git apply\n\nAlternative:\n          git checkout @{-1} t/\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"191140","messageId":"7vpqaev9gt.fsf@alter.siamese.dyndns.org","threadId":"30428","inReplyTo":"m262c6h8ft.fsf@igel.home","subject":"Re: git-scm.com refresh","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-08T18:00:50Z","receivedAt":"2012-05-08T18:00:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab <schwab@linux-m68k.org> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> I encountered another example yesterday after sending the above message\n>> [*1*].  I was fixing one small bug, and had a commit that updates code and\n>> adds a test vector.  It is a single commit on top of the current branch\n>> tip, which allegedly as a buggy code.\n>>\n>> Then I wanted to double check that the bug really existed before the fix.\n>>\n>> \tgit checkout HEAD^\n>>         git show @{-1} t/ | git apply\n>\n> Alternative:\n>           git checkout @{-1} t/\n\nTrue in this case, but that is usable when \"diff @{-1}^ @{-1}\" happens to\nbe the _only_ change to your current state, so it won't be a general\nsubstitute for the \"diff | apply\" pipeline.\n"},{"id":"191247","messageId":"20120509221336.GD74366@book.hvoigt.net","threadId":"30428","inReplyTo":"vpqfwbbitxn.fsf@bauges.imag.fr","subject":"Re: git-scm.com refresh","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-05-09T22:13:43Z","receivedAt":"2012-05-09T22:13:43Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Mon, May 07, 2012 at 11:04:52PM +0200, Matthieu Moy wrote:\n> Scott Chacon <schacon@gmail.com> writes:\n> \n> > Let me know if you run into anything or there are any features you\n> > would like to see.\n> \n> On http://git-scm.com/community one can see how to post and how to read\n> the archives of the mailing-list, but not how to subscribe. I guess you\n> need to add a link to http://vger.kernel.org/vger-lists.html#git\n\nOne thing I noticed is that there is no link to the msysgit project for\nthe windows development under community. The only way you can find it is\nunder download when you look closely at the text when the download is\nstarting.\n\nCould we add some information about msysgit for windows development on\nthe community page?\n\nMaybe the same applies for other OS like the osx installer?\n\nCheers Heiko\n"}]}