{"thread":{"id":"43359","subject":"Re: How to view an old revision?","startedAt":"2006-11-01T14:20:52Z","lastAt":"2006-11-01T19:02:47Z","messageCount":7,"participants":["Matt McCutchen","Junio C Hamano","Andy Whitcroft"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296827","messageId":"3bbc18d20611010620m11e40402v44334a8c486a4932@mail.gmail.com","threadId":"43359","inReplyTo":null,"subject":"How to view an old revision?","fromName":"Matt McCutchen","fromEmail":"hashproduct+git@gmail.com","sentAt":"2006-11-01T14:20:52Z","receivedAt":"2006-11-01T14:20:52Z","isPatch":false,"sender":{"key":"hashproduct+git@gmail.com","avatar":null},"body":"Dear git people,\n\nHow do I view an old revision of a file without actually checking it\nout? This would be analogous to \"cvs checkout -r -p\". I've\nRTMed and STWed and can't seem to find a way.\n\n"},{"id":"296396","messageId":"4548AFA2.1040606@shadowen.org","threadId":"43359","inReplyTo":"3bbc18d20611010620m11e40402v44334a8c486a4932@mail.gmail.com","subject":"Re: How to view an old revision?","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-01T14:30:58Z","receivedAt":"2006-11-01T14:30:58Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Matt McCutchen wrote:\n> Dear git people,\n> \n> How do I view an old revision of a file without actually checking it\n> out? This would be analogous to \"cvs checkout -r -p\". I've\n> RTMed and STWed and can't seem to find a way.\n> \n\nSomething like the following:\n\n\tgit cat-file -p :\n\nFor example:\n\tgit cat-file -p tags/v1.4.3:git.c\n\tgit cat-file -p f5f75c652b9c2347522159a87297820103e593e4:git.c\n\n"},{"id":"294493","messageId":"3bbc18d20611010637s6d05aecbt98322b62cf7235e8@mail.gmail.com","threadId":"43359","inReplyTo":"4548AFA2.1040606@shadowen.org","subject":"Re: How to view an old revision?","fromName":"Matt McCutchen","fromEmail":"hashproduct+git@gmail.com","sentAt":"2006-11-01T14:37:50Z","receivedAt":"2006-11-01T14:37:50Z","isPatch":false,"sender":{"key":"hashproduct+git@gmail.com","avatar":null},"body":"On 11/1/06, Andy Whitcroft wrote:\n> git cat-file -p :\n\nNice! Thanks! I had guessed \"git cat-file -p /\"\nbut didn't try a colon as the separator. The colon syntax ought to be\nmentioned in the git-cat-file man page.\n\n"},{"id":"296883","messageId":"4548B32A.5030803@shadowen.org","threadId":"43359","inReplyTo":"3bbc18d20611010637s6d05aecbt98322b62cf7235e8@mail.gmail.com","subject":"Re: How to view an old revision?","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-01T14:46:02Z","receivedAt":"2006-11-01T14:46:02Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Matt McCutchen wrote:\n> On 11/1/06, Andy Whitcroft wrote:\n>> git cat-file -p :\n> \n> Nice! Thanks! I had guessed \"git cat-file -p /\"\n> but didn't try a colon as the separator. The colon syntax ought to be\n> mentioned in the git-cat-file man page.\n\nThere are some improvements in the documentation in 'next' but nothing\nwhich would make this easier for you to find.\n\nJunio, I wonder if we should be changing the usage for this command\nslightly. Currently, it mearly says as the identifier for the\nblob. Really this is as it supports symbolic naming in\naddition to raw sha1's. I also feel it would be very helpful if\n and family were documented as a glossary section in main\ngit manpage.\n\nSomething like this:\n\n:: is an sha1 for a commit, or any symbolic name for a\ncommit (see SPECIFYING REVISIONS in git-rev-parse)\n\nWhat do people think. I can do the munging about if its seems like a\nsane plan.\n\n"},{"id":"296093","messageId":"7vzmbb2m42.fsf@assigned-by-dhcp.cox.net","threadId":"43359","inReplyTo":"4548B32A.5030803@shadowen.org","subject":"Re: How to view an old revision?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-01T16:00:13Z","receivedAt":"2006-11-01T16:00:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Whitcroft writes:\n\n> Junio, I wonder if we should be changing the usage for this command\n> slightly. Currently, it mearly says as the identifier for the\n> blob. Really this is as it supports symbolic naming in\n> addition to raw sha1's. I also feel it would be very helpful if\n> and family were documented as a glossary section in main\n> git manpage.\n>\n> Something like this:\n>\n> :: is an sha1 for a commit, or any symbolic name for a\n> commit (see SPECIFYING REVISIONS in git-rev-parse)\n>\n> What do people think. I can do the munging about if its seems like a\n> sane plan.\n\nWhen we really want an object of type , we accept an object\nthat is not of type if there is a natural and unique\ndereferencing of that object to the type . We use word\n to describe such an object that dereferences to .\nFor example, ls-tree is about listing tree contents (so we want\na tree), but we accept a commit because the natural and unique\ndereferencing of a commit to a tree is to take its (toplevel)\ntree. We also accept a tag pointing at a commit because we can\ndereference it to the commit and then to its tree. Hence a tag\nthat points at either commit or a tree, and a commit are\ntree-ish.\n\n is an object which can be , , or\n. There is nothing -ish about it.\n\nI was actually reviewing the documentation of git-rev-parse and\nnoticed that it talks about naming objects in the section called\n\"SPECIFYING REVISIONS\". The title implies that it is about\ncommittish (because we think of \"revisions\" as something that is\nused in walking commit ancestry chains), but it actually talks\nabout naming objects of any type.\n\nIt is a good and comprehensive list when viewed as \"list of ways\nyou can name an object\", but both the title and the page the\nlist appears in put unfair emphasis of commits for that purpose,\nand it is hard to realize that what you learned there applies to\nnaming any type of objects. It is even harder to guess the list\nappears on that page, unless you are the one who is actively involved\nin the git list, when you want to know which manual page to look\nat in order to find out how you name an arbitrary object.\n\nWe could either\n\n (1) retitle the list and move it to git.txt (Symbolic\n Identifiers), and refer to it from pages that describe\n commands that take object names;\n\n (2) retitle the list and make it an includable snippet, similar\n to the way Documentation/diff-format.txt is used from pages\n that describe diff commands, and include it everywhere.\n\nI am slightly in favor of the latter. Although it has a bloat\nfactor in the generated documentation, docs are not novels and\nnot meant to be read from cover to cover, and duplicating\nrelevant information on each page is more useful than refering\nthe reader to jump around in the documentation set.\n"},{"id":"296587","messageId":"3bbc18d20611010825ha4063d6wacf4f997d4652d35@mail.gmail.com","threadId":"43359","inReplyTo":"7vzmbb2m42.fsf@assigned-by-dhcp.cox.net","subject":"Re: How to view an old revision?","fromName":"Matt McCutchen","fromEmail":"hashproduct+git@gmail.com","sentAt":"2006-11-01T16:25:35Z","receivedAt":"2006-11-01T16:25:35Z","isPatch":false,"sender":{"key":"hashproduct+git@gmail.com","avatar":null},"body":"On 11/1/06, Junio C Hamano wrote:\n> I was actually reviewing the documentation of git-rev-parse and\n> noticed that it talks about naming objects in the section called\n> \"SPECIFYING REVISIONS\". The title implies that it is about\n> committish (because we think of \"revisions\" as something that is\n> used in walking commit ancestry chains), but it actually talks\n> about naming objects of any type.\n\nThere's no way I would have known to look in git-rev-parse. My\ngit-rev-parse man page doesn't mention the colon syntax, but now I see\nthat part in git's gitweb; my man page must be too old. Either (1) or\n(2) would have been enough for me to figure out that the colon syntax\nwould do what I wanted, but to grab the attention of the less\npersistent user, it would be good to mention the particular case of\n\"git-cat-file :\" in the git-cat-file man page.\n\n"},{"id":"296167","messageId":"4548EF57.6030509@shadowen.org","threadId":"43359","inReplyTo":"7vzmbb2m42.fsf@assigned-by-dhcp.cox.net","subject":"Re: How to view an old revision?","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-01T19:02:47Z","receivedAt":"2006-11-01T19:02:47Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andy Whitcroft writes:\n> \n>> Junio, I wonder if we should be changing the usage for this command\n>> slightly. Currently, it mearly says as the identifier for the\n>> blob. Really this is as it supports symbolic naming in\n>> addition to raw sha1's. I also feel it would be very helpful if\n>> and family were documented as a glossary section in main\n>> git manpage.\n>>\n>> Something like this:\n>>\n>> :: is an sha1 for a commit, or any symbolic name for a\n>> commit (see SPECIFYING REVISIONS in git-rev-parse)\n>>\n>> What do people think. I can do the munging about if its seems like a\n>> sane plan.\n> \n> When we really want an object of type , we accept an object\n> that is not of type if there is a natural and unique\n> dereferencing of that object to the type . We use word\n> to describe such an object that dereferences to .\n> For example, ls-tree is about listing tree contents (so we want\n> a tree), but we accept a commit because the natural and unique\n> dereferencing of a commit to a tree is to take its (toplevel)\n> tree. We also accept a tag pointing at a commit because we can\n> dereference it to the commit and then to its tree. Hence a tag\n> that points at either commit or a tree, and a commit are\n> tree-ish.\n> \n> is an object which can be , , or\n> . There is nothing -ish about it.\n> \n> I was actually reviewing the documentation of git-rev-parse and\n> noticed that it talks about naming objects in the section called\n> \"SPECIFYING REVISIONS\". The title implies that it is about\n> committish (because we think of \"revisions\" as something that is\n> used in walking commit ancestry chains), but it actually talks\n> about naming objects of any type.\n> \n> It is a good and comprehensive list when viewed as \"list of ways\n> you can name an object\", but both the title and the page the\n> list appears in put unfair emphasis of commits for that purpose,\n> and it is hard to realize that what you learned there applies to\n> naming any type of objects. It is even harder to guess the list\n> appears on that page, unless you are the one who is actively involved\n> in the git list, when you want to know which manual page to look\n> at in order to find out how you name an arbitrary object.\n> \n> We could either\n> \n> (1) retitle the list and move it to git.txt (Symbolic\n> Identifiers), and refer to it from pages that describe\n> commands that take object names;\n> \n> (2) retitle the list and make it an includable snippet, similar\n> to the way Documentation/diff-format.txt is used from pages\n> that describe diff commands, and include it everywhere.\n> \n> I am slightly in favor of the latter. Although it has a bloat\n> factor in the generated documentation, docs are not novels and\n> not meant to be read from cover to cover, and duplicating\n> relevant information on each page is more useful than refering\n> the reader to jump around in the documentation set.\n\nI'll take a stab at this ...\n\n"}]}