{"thread":{"id":"16609","subject":"Git Books","startedAt":"2008-12-06T11:58:28Z","lastAt":"2008-12-06T23:48:10Z","messageCount":9,"participants":["Scott Chacon","Thomas Adam","Christian MICHON","Jakub Narebski","Paolo Ciarrocchi","Dilip M","nadim khemir","Björn Steinbrink","Deskin Miller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"97249","messageId":"d411cc4a0812060358ub640ea3kd04072c5640eef68@mail.gmail.com","threadId":"16609","inReplyTo":null,"subject":"Git Books","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2008-12-06T11:58:28Z","receivedAt":"2008-12-06T11:58:28Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey all,\n\nI have been talked into helping write a real, paper-based book on Git\nfor a publisher big enough that you may even see it in your local\nBorders or whatnot.  (And, it appears that Junio has been as well:\nhttp://gitster.livejournal.com/21616.html)\n\nSo, since I'm near the beginning of this process, I was wondering if\nthe group had any feedback as to what might be super helpful to\ninclude.  I mean, I have a pretty good layout and all, but if you\nwanted to point me to some threads that tend to crop up in the mailing\nlist and IRC channel from relative newcomers that I might be able to\nnip in the bud, I would like to.  I'm addressing the stuff that _I_\nhear a lot, and I'm scanning the IRC logs and list for topics, but I\nfigured many of you must answer the same questions all the time, too.\n\nThanks,\nScott\n"},{"id":"97250","messageId":"18071eea0812060409y33680534p6b9ad56dd5043538@mail.gmail.com","threadId":"16609","inReplyTo":"d411cc4a0812060358ub640ea3kd04072c5640eef68@mail.gmail.com","subject":"Re: Git Books","fromName":"Thomas Adam","fromEmail":"thomas.adam22@gmail.com","sentAt":"2008-12-06T12:09:59Z","receivedAt":"2008-12-06T12:09:59Z","isPatch":false,"sender":{"key":"thomas.adam22@gmail.com","avatar":"https://gravatar.com/avatar/137f9858bc6bfd5b2f743aefd988c81ce0cbd306248889df80e269519cfc8741?d=mp&s=160"},"body":"2008/12/6 Scott Chacon <schacon@gmail.com>:\n> So, since I'm near the beginning of this process, I was wondering if\n> the group had any feedback as to what might be super helpful to\n> include.  I mean, I have a pretty good layout and all, but if you\n> wanted to point me to some threads that tend to crop up in the mailing\n> list and IRC channel from relative newcomers that I might be able to\n> nip in the bud, I would like to.  I'm addressing the stuff that _I_\n> hear a lot, and I'm scanning the IRC logs and list for topics, but I\n> figured many of you must answer the same questions all the time, too.\n\nPerhaps you're able to share this layout?  Whilst I am not about to go\ntrawling through the archives, one thing I do know that comes up a\nlot, isn't so much how to use git to mimick coming from another SCM,\nbut more workflows -- that's the big stumbling point for people using\nGit.  I know I'd like to see that aspect in a Git book heavily\naddressed.\n\n-- Thomas Adam\n"},{"id":"97252","messageId":"46d6db660812060427h3c97efd9ie4aa604133aa3583@mail.gmail.com","threadId":"16609","inReplyTo":"d411cc4a0812060358ub640ea3kd04072c5640eef68@mail.gmail.com","subject":"Re: Git Books","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2008-12-06T12:27:52Z","receivedAt":"2008-12-06T12:27:52Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On Sat, Dec 6, 2008 at 12:58 PM, Scott Chacon <schacon@gmail.com> wrote:\n> Hey all,\n>\n> I have been talked into helping write a real, paper-based book on Git\n> for a publisher big enough that you may even see it in your local\n> Borders or whatnot.  (And, it appears that Junio has been as well:\n> http://gitster.livejournal.com/21616.html)\n>\n> So, since I'm near the beginning of this process, I was wondering if\n> the group had any feedback as to what might be super helpful to\n> include.  I mean, I have a pretty good layout and all, but if you\n> wanted to point me to some threads that tend to crop up in the mailing\n> list and IRC channel from relative newcomers that I might be able to\n> nip in the bud, I would like to.  I'm addressing the stuff that _I_\n> hear a lot, and I'm scanning the IRC logs and list for topics, but I\n> figured many of you must answer the same questions all the time, too.\n>\n> Thanks,\n> Scott\n> --\n\nworkflows, workflows, workflows...\n\ngitconfig/aliases best practices\n\ntips and tricks in branches (ex: parentless...) and in setting up git servers\n\nmy 3 cents :)\n\n-- \nChristian\n--\nhttp://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !\n"},{"id":"97254","messageId":"m34p1hihx4.fsf@localhost.localdomain","threadId":"16609","inReplyTo":"d411cc4a0812060358ub640ea3kd04072c5640eef68@mail.gmail.com","subject":"Re: Git Books","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-06T12:54:06Z","receivedAt":"2008-12-06T12:54:06Z","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> I have been talked into helping write a real, paper-based book on Git\n> for a publisher big enough that you may even see it in your local\n> Borders or whatnot.  (And, it appears that Junio has been as well:\n> http://gitster.livejournal.com/21616.html)\n> \n> So, since I'm near the beginning of this process, I was wondering if\n> the group had any feedback as to what might be super helpful to\n> include.  I mean, I have a pretty good layout and all, but if you\n> wanted to point me to some threads that tend to crop up in the mailing\n> list and IRC channel from relative newcomers that I might be able to\n> nip in the bud, I would like to.  I'm addressing the stuff that _I_\n> hear a lot, and I'm scanning the IRC logs and list for topics, but I\n> figured many of you must answer the same questions all the time, too.\n\nWhat I really would like to see in a paper book is _diagrams_, in the\nform of simple graphs (and not UML-like diagrams, of flow-control like\ndiagrams).  You can find them in various slides for presentations\n(among others Junio's talks), and sometimes in blog posts[1], but\nusually only as ASCII-diagrams[2] in git documentation.  (And the\nexamples in\"The Git Comminity Book\" I've seen so far are a bit too\ncomplicated).\n\nFor example explaining git object model, explaining refs: local\nbranches, remote-tracking branches and tags, explaining pulling and\npushing, explaining merging and 3-way merge algorithm are difficult to\ndo without diagrams; diagrams make it much easier to understand.\n\nOthers have emphasized workflows enough...\n\nFootnotes:\n==========\n[1] http://www.gnome.org/~federico/news-2008-11.html#pushing-and-pulling-with-git-1\n[2] This is understandable, as while AsciiDoc format makes it quite\n    good on promise to be easy to edit for non-tech users, AFAIK there\n    is no such format for diagrams and pictures.  PIC and Asymptote\n    nonwithstanding.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"97255","messageId":"4d8e3fd30812060456i43d2301clcf4e4724e1962939@mail.gmail.com","threadId":"16609","inReplyTo":"d411cc4a0812060358ub640ea3kd04072c5640eef68@mail.gmail.com","subject":"Re: Git Books","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-12-06T12:56:08Z","receivedAt":"2008-12-06T12:56:08Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 12/6/08, Scott Chacon <schacon@gmail.com> wrote:\n> Hey all,\n>\n> I have been talked into helping write a real, paper-based book on Git\n> for a publisher big enough that you may even see it in your local\n\n> Borders or whatnot.  (And, it appears that Junio has been as well:\n> http://gitster.livejournal.com/21616.html)\n>\n> So, since I'm near the beginning of this process, I was wondering if\n> the group had any feedback as to what might be super helpful to\n> include.  I mean, I have a pretty good layout and all, but if you\n> wanted to point me to some threads that tend to crop up in the mailing\n> list and IRC channel from relative newcomers that I might be able to\n> nip in the bud, I would like to.  I'm addressing the stuff that _I_\n> hear a lot, and I'm scanning the IRC logs and list for topics, but I\n> figured many of you must answer the same questions all the time, too.\n\nPlease spend lot of words about fetch and pull. These are the most\nhard to ùnderstand commands for people that are used to cvs and svn.\n\nBtw, i would love to see a git in a nutshell book in my native\nlanguage (italian).\nI'm willing to help writing and translating.\n\n\nCiao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\nhttp://mypage.vodafone.it/\n"},{"id":"97260","messageId":"c94f8e120812060539t4121e135i3568bb5ec0c71cab@mail.gmail.com","threadId":"16609","inReplyTo":"46d6db660812060427h3c97efd9ie4aa604133aa3583@mail.gmail.com","subject":"Re: Git Books","fromName":"Dilip M","fromEmail":"dilipm79@gmail.com","sentAt":"2008-12-06T13:39:29Z","receivedAt":"2008-12-06T13:39:29Z","isPatch":false,"sender":{"key":"dilipm79@gmail.com","avatar":"https://gravatar.com/avatar/9417e308513ce9251de2802a026c72eb164e6c9b9d7143a3ee13f6ed0c4d1bd5?d=mp&s=160"},"body":"On Sat, Dec 6, 2008 at 5:57 PM, <christian.michon@gmail.com> wrote:\n> workflows, workflows, workflows...\n>\n> gitconfig/aliases best practices\n>\n> tips and tricks in branches (ex: parentless...) and in setting up git servers\n\nWork flows, setting up the GIT server, publishing codes,....would be\n_really_ helpful to great extent....and help a lot in deploying GIT\n\nThe work flow something like...http://source.android.com/submit-patches/workflow\n\n\n--\nDilip\n"},{"id":"97262","messageId":"200812061538.17700.nadim@khemir.net","threadId":"16609","inReplyTo":"m34p1hihx4.fsf@localhost.localdomain","subject":"Re: Git Books","fromName":"nadim khemir","fromEmail":"nadim@khemir.net","sentAt":"2008-12-06T14:38:17Z","receivedAt":"2008-12-06T14:38:17Z","isPatch":false,"sender":{"key":"nadim@khemir.net","avatar":null},"body":"On Saturday 06 December 2008 13.54.06 Jakub Narebski wrote:\n> \"Scott Chacon\" <schacon@gmail.com> writes:\n> > I have been talked into helping write a real, paper-based book on Git\n> > ...\n>\n> What I really would like to see in a paper book is _diagrams_, in the\n> form of simple graphs (and not UML-like diagrams, of flow-control like\n> diagrams).\n\nI was thinking about buying the pdf below. The little I can see looks like \nthere are a bunch of diagrams in it.\n\nhttp://peepcode.com/products/git-internals-pdf\n\n> You can find them in various slides for presentations \n> (among others Junio's talks), and sometimes in blog posts[1], but\n> usually only as ASCII-diagrams[2] in git documentation.  (And the\n> examples in\"The Git Comminity Book\" I've seen so far are a bit too\n> complicated).\n\nI like doing my ASCII-diagrams with Asciio, unsurprizingly.\n\n\n                                         ********\n                                         * HEAD *\n                                         ********\n                                             |\n                                             v\n                           .-----.      .--------.\n                           | tag |      | branch |\n                           '-----'      '--------'\n                              |              |\n                              v              v\n..........               ..........     ..........\n. commit .<--------------. commit .<----. commit .\n..........               ..........     ..........\n     |                        |              |\n     v                        v              v\n .------.                 .------.       .------.\n | tree |--------.--------| tree |       | tree |\n '------'        |        '------'       '------'\n     |           v            |              |\n     v       .------.         v              v\n .------.    | blob |     .------.       .------.\n | tree |--. '------'  .--| tree |       | blob |\n '------'  |           |  '------'       '------'\n           '-----.-----'      |\n                 |            v\n                 v        .------.\n             .------.     | tree |\n             | blob |     '------'\n             '------'         |\n                              v\n                          .------.\n                          | blob |\n                          '------'\n\ncheers, Nadim.\n"},{"id":"97276","messageId":"20081206194515.GA4721@atjola.homenet","threadId":"16609","inReplyTo":"d411cc4a0812060358ub640ea3kd04072c5640eef68@mail.gmail.com","subject":"Re: Git Books","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-12-06T19:45:15Z","receivedAt":"2008-12-06T19:45:15Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.12.06 03:58:28 -0800, Scott Chacon wrote:\n> So, since I'm near the beginning of this process, I was wondering if\n> the group had any feedback as to what might be super helpful to\n> include.  I mean, I have a pretty good layout and all, but if you\n> wanted to point me to some threads that tend to crop up in the mailing\n> list and IRC channel from relative newcomers that I might be able to\n> nip in the bud, I would like to.  I'm addressing the stuff that _I_\n> hear a lot, and I'm scanning the IRC logs and list for topics, but I\n> figured many of you must answer the same questions all the time, too.\n\nJust some random thoughts:\n\nPlease explain HEAD early on, and what it actually means. I've seen\nquite a number of people understanding HEAD as, for example, a magic\nkeyword, a branch property, or a _direct_ reference to the latest commit\non the branch they have checked out. Especially the last one has really\nconfused the hell out of some people when they came across the concept\nof a detached HEAD.\n\nExplaining remote tracking branches early on, say after the first\n\"clone\" is also important I guess. A number of readers will probably\njust \"dive in\" when they learned a few commands and clone some random\nrepo to start playing. Unless Murphy lets us down, they'll clone a repo\nthat has multiple branches and will sit there, wondering how to get one\nof the branches that only exist as remote tracking branches in their\nrepo.\n\nAnd for commands, it's IMHO best to always start with the \"full blown\"\nform, and only then, after introducing the command and what it does,\nstart to talk about short forms and how you can leave out some arguments\nand fall back to defaults.\n\nFor example:\n\nrebase:\nStart with \"rebase --onto <onto> <upstream> <branch>\" and how that takes\nthe commits from <upstream>..<branch> and \"replays\" them on top of\n<onto>. In my experience, starting with that version and showing how it\naffects the commit DAG helps people to actually understand what happens,\nwhile a plain \"git rebase master\" seems like pure magic to some, because\nyou can't even use the arguments to explain why and where things are\nplaced, or you start telling how those are all defaults, and then have\nto explain everything all over again, when you use the explicit form for\nmore complicated things and people seem to get confused by that.\n\nfetch:\nInclude refspecs in the first examples and show how a missing rhs causes\nthe fetched stuff to be stored in FETCH_HEAD. And only then go on to\ntell that remotes usually have a default refspec in their config, and\nthat you can thus omit the refspecs when you fetch from a remote.\n\npush:\nrefspecs again. Maybe start with pushing a single branch/tag/whatever,\nexplicitly, eg. \"git push origin refs/heads/master:refs/heads/master\",\nand only then introduce the DWIM stuff like \"git push origin master\".\nSame thing for the default \":\" refspec, please mention what that refspec\nmeans and that it is the default when no refspec is given (either on the\ncommand line or in the config). A lot of people don't seem to know about\nrefspecs at all, and the \"matching branch names\" refspec is IMHO worth\nbeing mentioned, as I've seen a bunch of questions lately that could be\nanswered by explaining that. For example, updating matching branches and\npushing a new tag at once, or having a push config that pushes one or\nmore branches to differently named branches on the remote, but using the\nname matching for all other. And personally, I also like \"git push\norigin : v1.2.3\" better than pushing twice or naming my branches\nexplicitly :-)\n\nBjörn\n"},{"id":"97290","messageId":"20081206234810.GA8809@euler","threadId":"16609","inReplyTo":"20081206194515.GA4721@atjola.homenet","subject":"Re: Git Books","fromName":"Deskin Miller","fromEmail":"deskinm@umich.edu","sentAt":"2008-12-06T23:48:10Z","receivedAt":"2008-12-06T23:48:10Z","isPatch":false,"sender":{"key":"deskinm@umich.edu","avatar":"https://gravatar.com/avatar/d340a0e612cdf0a79535c71863c0b4c535e9aba63b42032226ae903e638b64f9?d=mp&s=160"},"body":"On 2008.12.06 03:58:28 -0800, Scott Chacon wrote:\n> So, since I'm near the beginning of this process, I was wondering if\n> the group had any feedback as to what might be super helpful to\n> include.  I mean, I have a pretty good layout and all, but if you\n> wanted to point me to some threads that tend to crop up in the mailing\n> list and IRC channel from relative newcomers that I might be able to\n> nip in the bud, I would like to.  I'm addressing the stuff that _I_\n> hear a lot, and I'm scanning the IRC logs and list for topics, but I\n> figured many of you must answer the same questions all the time, too.\n\nI agree with pretty much all of the other suggestions made thus far.\nOne I'd vote for is to explain why pushing to a non-bare repository\ndoesn't magically update the working tree as well; I'd say it's easily\none of the most repeated questions on #git.\n\nI also vote for addressing workflows heavily.  Also, I think a reference\nsection akin to Tv's 'Git for Computer Scientists' page[1] would be\nhandy; I find understanding how git represents the project to inform\nalmost every interesting question about how to accomplish one's goals in\na particular situation.\n\nDeskin Miller\n\n[1] http://eagain.net/articles/git-for-computer-scientists/\n"}]}