{"thread":{"id":"13301","subject":"Yet another Git tutorial","startedAt":"2008-04-28T06:39:46Z","lastAt":"2008-04-30T23:17:20Z","messageCount":14,"participants":["John Wiegley","Johan Herland","Jeff King","Brian Gernhardt","Paolo Bonzini","Bob Hiestand","Dmitry Potapov","Junio C Hamano","Matt Graham","Robert Haines"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"75347","messageId":"2D3D2E55-74C7-4373-BC22-9CF4C26C197D@newartisans.com","threadId":"13301","inReplyTo":null,"subject":"Yet another Git tutorial","fromName":"John Wiegley","fromEmail":"johnw@newartisans.com","sentAt":"2008-04-28T06:39:46Z","receivedAt":"2008-04-28T06:39:46Z","isPatch":false,"sender":{"key":"johnw@newartisans.com","avatar":null},"body":"I published another tutorial on Git today, this one describing the  \nsystem from a \"bottom up\" perspective.  I know it's been written about  \nthis way before, but I was aiming at a bit more thoroughness, and a  \npaced introduction to the basics.\n\nThere's a link to the PDF is in the following blog post:\n\n   http://www.newartisans.com/blog_files/git.from.bottom.up.php\n\nThanks,\n   John\n\np.s. My thanks to the folks on IRC who read it and gave comments,  \nespecially reuss, com4 and drewr.\n"},{"id":"75359","messageId":"200804281127.18162.johan@herland.net","threadId":"13301","inReplyTo":"2D3D2E55-74C7-4373-BC22-9CF4C26C197D@newartisans.com","subject":"Re: Yet another Git tutorial","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-04-28T09:27:18Z","receivedAt":"2008-04-28T09:27:18Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 28 April 2008, John Wiegley wrote:\n> I published another tutorial on Git today, this one describing the  \n> system from a \"bottom up\" perspective.  I know it's been written about  \n> this way before, but I was aiming at a bit more thoroughness, and a  \n> paced introduction to the basics.\n> \n> There's a link to the PDF is in the following blog post:\n> \n>    http://www.newartisans.com/blog_files/git.from.bottom.up.php\n\nSome comments after a quick read-through:\n\n(in general) In you examples, you are using the \"git foo\" notation, while\nyou're using the \"git-foo\" notation when referring to git commands elsewhere\nin the text. This is probably OK; just be aware that the dashed form of the\ncommands will disappear in a future git version.\n\n(in general II) You mention \"git prune\" a couple of places. I think \"git gc\"\nis the command we encourage new users to use, so you might want to use that\ninstead.\n\n(p.2 (and p.19-20)) I think most people say \"index\" and not \"index cache\".\nIn the git codebase, \"index\" and \"cache\" are often confused (I think Linus\ninitially named it \"cache\"), but I think from a user perspective, we try to\nuse the term \"index\".\n\n(p.3) In the simple diagram, you show the 'checkout' activity as an arrow\ndirectly from 'Repository' to 'Working Tree'. What actually happens on\ncheckout is copying the appropriate tree object into the index, and then\napplying the index onto the working tree. IOW if you want to be 100% correct\nthe checkout arrow should go through the index. But this is only a minor\nissue; if you feel understanding is better conveyed by the existing diagram,\nplease don't change.\n\n(p.9) \"But if I pass the -f flag to git-checkout, it becomes identical to\ngit-reset --hard\": In the context of the command above (resetting the\nworking tree to 5f1bc85) there are in fact no difference between the two\ncommands. However, in general, there is one crucial difference between \"git\nreset --hard\" and \"git checkout -f\": \"git reset --hard\" will rewrite which\ncommit the current branch points at, whereas \"git checkout -f\" will not.\n(I see you treat this later in \"To reset, or not to reset\", but I think it\nshould be fixed on p.9 as well.)\n\n(p.10) In the diagram at the top, the arrow from the root tree object to\nHEAD commit is labelled \"parent\". I think this label rather belongs on the\narrow from the HEAD commit to its parent.\n\n(p.11) \"name~10\" Just to make things perfectly clear, I would state that\n\"name~10\" is equivalent to \"name^^^^^^^^^^\".\n\n(p.11-12) This entire list is prefixed with \"nam[ing] commits - and ranges\nof commits\", so in a strict sense \"name:file\" and \"name{tree}\" does not\nbelong here. But you have to put them somewhere...\n\n(p.15) \"Even the transformation from X to W is changed\": I think this should\nbe the other way around: \"W to X\".\n\n(p.16) \"For every commit this that involves conflicts\": s/ this//?\nAlso, in the preceding sentence, I'd prefer \"...to its (now rewritten)\nparent commit\" instead of the current \"...to its (now) rewritten parent\ncommit\".\n\n\nOtherwise, I think it's informative and well-written. Nice work.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"75360","messageId":"20080428093628.GA20299@sigill.intra.peff.net","threadId":"13301","inReplyTo":"2D3D2E55-74C7-4373-BC22-9CF4C26C197D@newartisans.com","subject":"Re: Yet another Git tutorial","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-28T09:36:28Z","receivedAt":"2008-04-28T09:36:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 28, 2008 at 02:39:46AM -0400, John Wiegley wrote:\n\n> I published another tutorial on Git today, this one describing the\n> system from a \"bottom up\" perspective.  I know it's been written about\n> this way before, but I was aiming at a bit more thoroughness, and a\n> paced introduction to the basics.\n\nI like the \"bottom up\" approach as well (and in fact, I gave a similarly\nstructured talk to some computer scientists a month or two ago). But I\nhave seen some comments from some users that imply to me they prefer a\n\"top down\" approach.\n\nSo I'm curious: did you write this to show to some specific audience,\nand if so, how did the audience receive it? IOW, did they like the\n\"bottom up\" technique?\n\n-Peff\n"},{"id":"75397","messageId":"4557C7EE-2B56-4836-A2AC-09EAF05FD95C@silverinsanity.com","threadId":"13301","inReplyTo":"2D3D2E55-74C7-4373-BC22-9CF4C26C197D@newartisans.com","subject":"Re: Yet another Git tutorial","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-04-28T16:30:30Z","receivedAt":"2008-04-28T16:30:30Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Apr 28, 2008, at 2:39 AM, John Wiegley wrote:\n\n> I published another tutorial on Git today, this one describing the  \n> system from a \"bottom up\" perspective.  I know it's been written  \n> about this way before, but I was aiming at a bit more thoroughness,  \n> and a paced introduction to the basics.\n\nVery interesting tutorial.  Doesn't teach me anything, of course, but  \nI've been using git for a good long time.  But I'm going to save this  \nand point it out to my technical friends who are interesting in git,  \nas this does a better job of teaching them what it's actually doing  \n\"behind the scenes\" than most tutorials I've seen.\n\nThat said, my comments:\n\n(p.4) On my system, `echo \"Hello, world\\!\" > greeting` puts the  \nbackslash into greeting, which in turn changes my SHA1.  (Using bash  \n3.1.17.)  Of course, leaving it out leaves an error.  To avoid  \nproblems with different shells perhaps you should use something like:\n\n$ cat > greeting <<EOF\nHello, world!\nEOF\n\nOf course, this issue could also be solved by leaving out the  \nexclamation point, as long as you update the hashes of the objects  \nfrom that point on.\n\n(p.4-5) You determine the hash for your file as  \n\"af5626b4a114abcb82d63db7c8082c3c4756e51b\", then use `git cat-file -t  \naf5626b` to find it, and print the type.  You should use this as an  \nopportunity to mention the convenience of git expanding SHA1  \nabbreviations, rather than leave it implicit.  In documentation, it's  \na good idea to never use something you haven't explained.\n\n(p.5) Your reference to hand waving is unnecessary, as you defined  \nHEAD in your lexicon on p.2.  Reinforcing that your current commit is  \nHEAD is fine, but the apology is unneeded and distracting.  Perhaps  \nsomething like:  \"If we want to see the contents of our commit, all we  \nhave to do is list the tree for HEAD (which always refers to the last  \ncommit on the current branch):\"\n\n(p.5) Instead of using `git rev-list HEAD | head -1`, you can also  \njust use `git rev-list -1 HEAD`.  And instead of that, what you really  \nwant to be using is `git rev-parse HEAD` since you're trying to  \nconvert HEAD to a SHA1, not get HEAD's history.\n\n(p.7) I can't help but feel that telling the user to do `rm -fr *` is  \na bad plan.  `rm -rf greeting .git` is better: It will remove all the  \nfiles you've told them to create anyway, without causing huge  \nheadaches if they type it in the wrong terminal.  Plus, removing and  \nrecreating the greeting file isn't really necessary, so why do it?\n\n(p.8) Mentioning again that the commit SHA1 is going to be different  \nwould be a good idea.  And at this point you should mention why:  \ndifferent authors and dates.\n\nOn Apr 28, 2008, at 5:27 AM, Johan Herland wrote:\n\n> (p.9) \"But if I pass the -f flag to git-checkout, it becomes  \n> identical to\n> git-reset --hard\": In the context of the command above (resetting the\n> working tree to 5f1bc85) there are in fact no difference between the  \n> two\n> commands. However, in general, there is one crucial difference  \n> between \"git\n> reset --hard\" and \"git checkout -f\": \"git reset --hard\" will rewrite  \n> which\n> commit the current branch points at, whereas \"git checkout -f\" will  \n> not.\n> (I see you treat this later in \"To reset, or not to reset\", but I  \n> think it\n> should be fixed on p.9 as well.)\n\n\nI really want to agree with this comment. `git reset --hard` and `git  \ncheckout -f` are not identical, and you shouldn't put that  \nmisconception into place.  It may be enough to call them similar and  \nsay you will explain the difference later.\n\n(p.10) Is there a particular reason why one blob is white and the  \nothers have a gradient?  It makes that one square stand out for no  \napparent purpose.\n\nOn Apr 28, 2008, at 5:27 AM, Johan Herland wrote:\n\n> (p.11-12) This entire list is prefixed with \"nam[ing] commits - and  \n> ranges\n> of commits\", so in a strict sense \"name:file\" and \"name{tree}\" does  \n> not\n> belong here. But you have to put them somewhere...\n\nPerhaps you should say: \"There are many way to name objects --  \ncommits, ranges of commits, trees, and blobs --\"\n\n(p.12) \"name{tree}\" should be \"name^{tree}\".\n\n(p.12) \"If either name1 or name2 may be omitted, HEAD is used in its  \nplace.\"  This should be \"If either name1 or name2 is omitted, HEAD is  \nused in its place.\"\n\n(p.12) You describe --author and --committer without describing why  \nthese may be different.  You could introduce the difference when  \ntalking about rebase.\n\n(p.12) I'd also add an example that mixes several of these options,  \njust to demonstrate that it can be done.  For example: `--no-merges -- \ngrep=\"bug fix\" --since=\"1 month ago\"`.  A sentence or two about using  \napproximate dates and full dates would be nice as well.\n\n(p.14) Spelling: \"asterices\" should be \"asterisks\".  Your spelling may  \nbe considered technically correct but is not the common pluralization  \nby any means.  (And it threw me for a loop when I saw it.)\n\nThis is a good place to really learn the guts of Git.  But as a  \ntutorial, it lacks any description of how to do the D part of DVCS.   \nSections on pull/push, remotes, and patches would be useful for a new  \nuser.  You could get a new user working on a copy of the git repo and  \nsending a patch to the list in only a few pages describing clone,  \nformat-patch, and possibly send-email.  If you were ambitious you  \ncould add the receiving side of dealing patches working up from apply  \nto am.  And of course, describing clone should also involve using  \ninit, remote, and pull.\n\nBut of course, there are other places to learn these things.  At the  \nleast adding URLs to tutorials that do describe pull, pull, and  \npatches would be nice ending.\n\n~~ Brian\n"},{"id":"75401","messageId":"4815FE06.90002@gnu.org","threadId":"13301","inReplyTo":"4557C7EE-2B56-4836-A2AC-09EAF05FD95C@silverinsanity.com","subject":"Re: Yet another Git tutorial","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-28T16:40:38Z","receivedAt":"2008-04-28T16:40:38Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"> (p.4) On my system, `echo \"Hello, world\\!\" > greeting` puts the \n> backslash into greeting.  Of course, leaving it out leaves an error.\n\nUsing single quotes, as in `echo 'Hello, world!'`, should work fine.\n\nPaolo\n"},{"id":"75403","messageId":"9784D772-3CC5-47A5-9FD2-DB4F729FC069@silverinsanity.com","threadId":"13301","inReplyTo":"4815FE06.90002@gnu.org","subject":"Re: Yet another Git tutorial","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-04-28T16:42:49Z","receivedAt":"2008-04-28T16:42:49Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Apr 28, 2008, at 12:40 PM, Paolo Bonzini wrote:\n\n>> (p.4) On my system, `echo \"Hello, world\\!\" > greeting` puts the  \n>> backslash into greeting.  Of course, leaving it out leaves an error.\n>\n> Using single quotes, as in `echo 'Hello, world!'`, should work fine.\n\nOf course, I forget this simple option.\n\n~~ Brian\n"},{"id":"75441","messageId":"cc29171c0804281245n7715c2fta2b5c8f3155bfa40@mail.gmail.com","threadId":"13301","inReplyTo":"2D3D2E55-74C7-4373-BC22-9CF4C26C197D@newartisans.com","subject":"Re: Yet another Git tutorial","fromName":"Bob Hiestand","fromEmail":"bob.hiestand@gmail.com","sentAt":"2008-04-28T19:45:44Z","receivedAt":"2008-04-28T19:45:44Z","isPatch":false,"sender":{"key":"bob.hiestand@gmail.com","avatar":null},"body":"On Mon, Apr 28, 2008 at 1:39 AM, John Wiegley <johnw@newartisans.com> wrote:\n\n>   http://www.newartisans.com/blog_files/git.from.bottom.up.php\n\n  Under the section \"Doing a mixed reset\" you mention that \"It doesn't\nchange the working tree, and it doesn't change any of\nthe repository's references.\"  However, doing a --mixed reset does\nchange your references, just not your working tree.\n\nThank you,\n\nbob\n"},{"id":"75447","messageId":"8D57D711-5C57-43AB-AD9D-45E964E945A5@newartisans.com","threadId":"13301","inReplyTo":"200804281127.18162.johan@herland.net","subject":"Re: Yet another Git tutorial","fromName":"John Wiegley","fromEmail":"johnw@newartisans.com","sentAt":"2008-04-28T20:11:57Z","receivedAt":"2008-04-28T20:11:57Z","isPatch":false,"sender":{"key":"johnw@newartisans.com","avatar":null},"body":"On Apr 28, 2008, at 5:27 AM, Johan Herland wrote:\n\n> Some comments after a quick read-through:\n\nMy thanks to everyone for the excellent feedback!  You've made some  \ngreat points and I will try to incorporate them all during this week.   \nI'll post to the list when a final version is available.\n\nIn the meantime, if you haven't sent edits yet, please do.  I'm not  \nsure if this tutorial should grow any further, or if -- as someone  \nsuggested -- I should just add a springboard note at the end linking  \nto other articles, which do a fine job of introducing the user to  \ntypical usage scenarios.  I guess it can't quite be called a  \n\"tutorial\" if it never mentions the \"clone\" command.  Perhaps calling  \nit a \"design intro\" or \"meta-tutorial\" would be better.\n\nJohn\n"},{"id":"75474","messageId":"20080428222717.GA6160@dpotapov.dyndns.org","threadId":"13301","inReplyTo":"2D3D2E55-74C7-4373-BC22-9CF4C26C197D@newartisans.com","subject":"Re: Yet another Git tutorial","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-04-28T22:27:17Z","receivedAt":"2008-04-28T22:27:17Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Apr 28, 2008 at 02:39:46AM -0400, John Wiegley wrote:\n> I published another tutorial on Git today, this one describing the  \n> system from a \"bottom up\" perspective.  I know it's been written about  \n> this way before, but I was aiming at a bit more thoroughness, and a  \n> paced introduction to the basics.\n> \n> There's a link to the PDF is in the following blog post:\n> \n>   http://www.newartisans.com/blog_files/git.from.bottom.up.php\n\nIn addition to what was mentioned before me:\n\nOn page 6, instead of `git show --pretty=format:%T HEAD | head -1`, it\nis better to use `git log -1 --pretty=format:'%T' HEAD`. In general,\n`git show <commit-object>` is `git log -1 -p <commit-object>`, and\nyou do not need diff here.\n\nOn page 7:\n> This blob doesn't live in a tree yet, nor are there any commits.\n\nIt is probably nit-picking, but blobs never live in trees. They may\nonly be referenced by trees, while they always reside in 'objects'.\nAt this point, the blob is already placed into 'objects', but it is\nnot referenced by any tree, but only by index. So if you decide not\nto commit this file then this blob will become dangling.\n\nOn page 10:\n> circles are commit objects, and all but the first link to one or more\n> parent commits, thus forming a \"history\"\n\nThough typically there is only one commit object in Git repository\nwithout a parent, it could be more than one.\n\n> every commit holds a tree, and every tree must have at least one blob\n> in its leaves\n\nIf there is no files in the current commit then the commit object\nwill reference to an empty tree, i.e. without any blob in it.\n\n\nOn page 12:\n> name1..name2\n> \n> The syntax to the le refers to all the commits between name1\n> and name2, inclusive.\n\nActually, inclusive name2 but excluding name1. IMHO, it is better to\ndescribe it as:\n`name1..name2` is a short-hand for `^name1 name2`, which is equivalent\nto `name2 --not name1`, i.e. all commits in name1 excluding those that\nare part of name2.\n\n> name1...name2\n> \n> For example, if you had two development branches, \"foo\" and\n> \"bar\", you could show all the commits which had happened on\n> bar since their common ancestor using this command:\n\nNot true. It shows all commits on both \"foo\" and \"bar\" that's happened\nsince their common ancestors. In other words, `name1...name2` is\nequivalent to `name1 name2 --not $(git-merge-base --all name1 name2)`.\nThe '--all' flag means to consider their all ancestors, not just first\none.\n\n\nBTW, maybe it would be useful to mention `git log -S<string>` somewhere\nas a better alternative to `git blame`, because people with CVS/SVN\nbackground tend to abuse `git blame` while `git log -S` is usually more\nconvenient and more efficient.\n\n\nDmitry\n"},{"id":"75477","messageId":"7v63u1blkm.fsf@gitster.siamese.dyndns.org","threadId":"13301","inReplyTo":"20080428222717.GA6160@dpotapov.dyndns.org","subject":"Re: Yet another Git tutorial","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-28T23:34:33Z","receivedAt":"2008-04-28T23:34:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Potapov <dpotapov@gmail.com> writes:\n\n> On Mon, Apr 28, 2008 at 02:39:46AM -0400, John Wiegley wrote:\n>> I published another tutorial on Git today, this one describing the  \n>> system from a \"bottom up\" perspective.  I know it's been written about  \n>> this way before, but I was aiming at a bit more thoroughness, and a  \n>> paced introduction to the basics.\n>> \n>> There's a link to the PDF is in the following blog post:\n>> \n>>   http://www.newartisans.com/blog_files/git.from.bottom.up.php\n>\n> In addition to what was mentioned before me:\n>\n> On page 6, instead of `git show --pretty=format:%T HEAD | head -1`, it\n> is better to use `git log -1 --pretty=format:'%T' HEAD`. In general,\n> `git show <commit-object>` is `git log -1 -p <commit-object>`, and\n> you do not need diff here.\n\nI may be misunderstanding what the discussion is about as I was not\nfollowing the thread, but is this a contest to find the most expensive way\nto spell \"git rev-parse HEAD^{tree}\"?\n"},{"id":"75478","messageId":"7vskx5a519.fsf@gitster.siamese.dyndns.org","threadId":"13301","inReplyTo":"2D3D2E55-74C7-4373-BC22-9CF4C26C197D@newartisans.com","subject":"Re: Yet another Git tutorial","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-29T00:17:06Z","receivedAt":"2008-04-29T00:17:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Page #5; after teaching \"cat-file -t\" it would make sense to teach\n\"cat-file blob\" to view what was stored.\n\nPage #5; likewise, \"cat-file -t HEAD\" to inspect and \"cat-file commit\nHEAD\" to show its contents would be a much better \"bottom-up\" way to show\nhow the pieces fit together, instead of doing \"show --pretty=format:%T\".\n\nPage #6; \"HEAD tag\"???\n\nPage #6; s/my system/my repository/, as you use that word a few lines\nlater.\n\nYou use \"id\", \"hash id\", \"hash number\", \"hash\" etc. and have your readers\nguess that you are talking about the same thing.  It would be better to\nuse a single word consistently (the official name of this number is the\n\"object name\").\n\ns/index cache/the index/.\n\ns/tree owns blob/tree holds blob/, perhaps.\n\nPage #9; before this point, your tree owned blobs but now suddenly it\nreferences trees and blobs.  There should be a mention of this recursive\nconstruction of a tree earlier soon after you introduced the tree\nobjects. \n\nPage #11: s/name:file/name:path/; notice that it can be non-files such as\nsymlinks and trees.\n\nPage #12: s/name{tree}/name^{tree}/.\n\nPage #12: name1..name2; \"between name1 and name2, inclusive\"?  This\nexcludes the left end.  \"Everything reachable from name2 except the ones\nreachable from name1\".\n\nPage #12: name1...name2.  This is a symmetric difference for \"git log\"\nfamily of commands (iow when you talk about set of commits) which means\n\"Reachable either from name1 or name2 but not from both\".  When used with\n\"git diff\" to name two endpoints, this means what you described\n(differences since the common ancestor of these two to name2).\n\nPage #12: master..; it would also be useful to mention ..other here.\n\nPage #17: The example makes me wonder what you did exactly to commit I.\nIt would contain roughly an equivalent of squashed B+C together, which may\nor may not be what you want.\n\nPage #18: There is no \"two different things\" reason behind the name.  It\nwas originally called \"directory cache\" and then renamed to \"the index\".\nThese days, most of the time we use these two words interchangeably, but\nwhen we are picky, index tends to mean the file on the filesystem\n(i.e. $GIT_INDEX_FILE aka $GIT_DIR/index) while cache tends to mean the\nin-core structure (i.e. the_index.cache aka active_cache).\n\nPage #22: \"git reset --mixed\" will remove blobs???  You surely did not\nmean that.  It just reverts the staged contents to that of the HEAD (or\nwhichever commit you named and moved your HEAD to).\n\nPage #24: saves your work in the stash \"for the current branch\"???  There\nis no per-branch stash.  You can stash, switch branches and then apply the\nstashed change to the other branch.\n"},{"id":"75481","messageId":"1c5969370804281825m378b8714q809f13eb6192623@mail.gmail.com","threadId":"13301","inReplyTo":"2D3D2E55-74C7-4373-BC22-9CF4C26C197D@newartisans.com","subject":"Re: Yet another Git tutorial","fromName":"Matt Graham","fromEmail":"mdg149@gmail.com","sentAt":"2008-04-29T01:25:51Z","receivedAt":"2008-04-29T01:25:51Z","isPatch":false,"sender":{"key":"mdg149@gmail.com","avatar":"https://gravatar.com/avatar/a1f130a60a6550f75e8d7d3849e58e46494f36bfaf764a38cfd695ac85de8576?d=mp&s=160"},"body":"On Mon, Apr 28, 2008 at 2:39 AM, John Wiegley <johnw@newartisans.com> wrote:\n> I published another tutorial on Git today, this one describing the system\n> from a \"bottom up\" perspective.  I know it's been written about this way\n> before, but I was aiming at a bit more thoroughness, and a paced\n> introduction to the basics.\n>\n>  There's a link to the PDF is in the following blog post:\n>\n>   http://www.newartisans.com/blog_files/git.from.bottom.up.php\n\nThe arrows in your diagrams go the opposite way I expected, but I\nmight have been execting the wrong thing.\n"},{"id":"75623","messageId":"DCF8F30E-5D82-4AE8-BFE1-25065BC3517A@newartisans.com","threadId":"13301","inReplyTo":"1c5969370804281825m378b8714q809f13eb6192623@mail.gmail.com","subject":"Re: Yet another Git tutorial","fromName":"John Wiegley","fromEmail":"johnw@newartisans.com","sentAt":"2008-04-30T01:40:27Z","receivedAt":"2008-04-30T01:40:27Z","isPatch":false,"sender":{"key":"johnw@newartisans.com","avatar":null},"body":"I've applied nearly everyone's corrections and uploaded the new  \nversion of the PDF.  Thanks again to everyone for such conscientious  \nreading!\n\n   http://www.newartisans.com/blog_files/git.from.bottom.up.php\n\nJohn\n"},{"id":"75722","messageId":"4818FE00.1080209@manchester.ac.uk","threadId":"13301","inReplyTo":"DCF8F30E-5D82-4AE8-BFE1-25065BC3517A@newartisans.com","subject":"Re: Yet another Git tutorial","fromName":"Robert Haines","fromEmail":"rhaines@manchester.ac.uk","sentAt":"2008-04-30T23:17:20Z","receivedAt":"2008-04-30T23:17:20Z","isPatch":false,"sender":{"key":"rhaines@manchester.ac.uk","avatar":null},"body":"John Wiegley wrote:\n> I've applied nearly everyone's corrections and uploaded the new version \n> of the PDF.  Thanks again to everyone for such conscientious reading!\n> \n>   http://www.newartisans.com/blog_files/git.from.bottom.up.php\n\nVery good tutorial. I'm working through it to fill in gaps in my git \nknowledge (of which there are many - stash for instance, very cool).\n\nOn page 5 your second git cat-file example is incorrect I think. It \nshould be:\n$ git cat-file blob af5626b\n\ni.e. you're missing the \"blob\" bit!\n\nCheers,\nRob\n"}]}