{"thread":{"id":"7004","subject":"Questions about git-rev-parse","startedAt":"2007-02-28T02:23:37Z","lastAt":"2007-03-01T02:16:09Z","messageCount":9,"participants":["Theodore Ts'o","Junio C Hamano","Theodore Tso","Linus Torvalds","Andy Parkins","Willhelm Busch"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"35754","messageId":"E1HMETh-0004BO-Lw@candygram.thunk.org","threadId":"7004","inReplyTo":null,"subject":"Questions about git-rev-parse","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2007-02-28T02:23:37Z","receivedAt":"2007-02-28T02:23:37Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"\nSo I was looking at git-rev-parse trying to understand the man page, as\nI was trying to understand how various commands can accept lists (or\nranges) of commits, and the man page raised a number of questions.\nFirst of all, the DESCRIPTION section doesn't quite parse as English:\n\n       Many  git  porcelainish commands take mixture of flags (i.e. parameters\n       that  begin  with  a  dash  -)  and  parameters  meant  for  underlying\n       git-rev-list  command  they use internally and flags and parameters for\n       other commands they use as the downstream of git-rev-list. \n\nBut, as best as I can gather that it's a helper function meant to do\nsome basic options parsing for those git porcelain commands that expect\nto take a set of revision ID's.\n\nThis raises some additional questions, though.  If the goal of this\ncommand is to parse out those options and arguments which are meant for\ngit-rev-list, why does it translate tag names to SHA id's:\n\n% git-rev-parse v1.5.0..v1.5.0.1\ndedb0faa48787839dbc47b7ca2507bda5924ec2c\n^6db027ffe03210324939b3dd655c4223ca023b45\n\nAfter all, git-rev-list can just as easily accept:\n\n\tgit-rev-list dedb0faa48787839dbc47b7ca2507bda5924ec2c \\\n\t\t^6db027ffe03210324939b3dd655c4223ca023b45\n\nas\n\n\tgit-rev-list v1.5.0..v1.5.0.1\n\nAlso, there are a number of options in git-rev-list which make it appear\nto be a general dumping ground of miscellaneous options.  \n\nFor example, it's not clear what \n\n\tgit-rev-parse --show-prefix\n\nand\n\n\tgit-rev-parse --show-cdup\n\nhave to do with the description of git-rev-parse as described in the\nDESCRIPTION section.  It seems to be completely miscellaneous extras\nthat were tacked on.  Or am I missing something?\n\nFinally, it seems rather unfortunate that certain bits of functionality\nsuch as --since and --until were hidden into git-rev-parse, since it\nmeans that some commands which are implemented as shell scripts are more\nlikely to use git-rev-parse, and will therefore support --since and\n--until, where as other commands which are implemented as built-in's,\nsuch as git-log, don't accept --since and --until.\n\nSo I'm wondering if I'm missing something about historical context,\nsince from looking at git-rev-parse, it looks like not a lot of thought\nwent into its design, and it has a bunch of stuff that grew via\naccretion; or maybe I'm not understanding why it was designed the way it\nwas?\n\nRegards,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"35756","messageId":"7vvehn2eds.fsf@assigned-by-dhcp.cox.net","threadId":"7004","inReplyTo":"E1HMETh-0004BO-Lw@candygram.thunk.org","subject":"Re: Questions about git-rev-parse","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-28T02:40:47Z","receivedAt":"2007-02-28T02:40:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Theodore Ts'o\" <tytso@mit.edu> writes:\n\n> So I'm wondering if I'm missing something about historical context,\n> since from looking at git-rev-parse, it looks like not a lot of thought\n> went into its design, and it has a bunch of stuff that grew via\n> accretion; or maybe I'm not understanding why it was designed the way it\n> was?\n\nYou are lacking historical context that our porcelain-ish were\nall Bourne shell scripts.  If you check out an old version (say\nv0.99), it would be apparent why translating symbolic names to\nobject names and canonicalizing a..b to b ^a were useful to help\nthem.\n\nThese days, \"log\" family got sufficiently smart that there are\nnot many reasons to write shell pipeline that has rev-list on\nthe upstream with diff-tree --stdin on the downstream anymore,\nand rev-parse outlived its original purpose of sifting between\nrev-list args/flags and others.\n"},{"id":"35759","messageId":"20070228025258.GD2178@thunk.org","threadId":"7004","inReplyTo":"7vvehn2eds.fsf@assigned-by-dhcp.cox.net","subject":"Re: Questions about git-rev-parse","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-28T02:52:58Z","receivedAt":"2007-02-28T02:52:58Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Feb 27, 2007 at 06:40:47PM -0800, Junio C Hamano wrote:\n> You are lacking historical context that our porcelain-ish were\n\nSo while I'm asking questions, where did the \"*-ish\" terminology come\nfrom, anyway?  For someone who is a relative newbie, terms like\ntree-ish and commit-ish seems like some kind of strange, git jargon.\nAnd this is the first time I've come across porcelian-ish.\n\nI had the mental model (which I had intuited, since no git\ndocumentation I could find had bothered to explain it) that -ish meant\nsomething like specifier, so \"tree-ish\" meant tree specifier, so a\ncommit id could get dereferenced into a tree id, so it could be used\nto specify a tree.\n\nBut that explanation doesn't explain \"porcelain-ish\".  \n\nSo what does -ish mean, really?  Where did it come from?  And if it\ndoes add value to use this wierd bit of git jargon, can we document it\nsomewhere, preferably in a tutorial and main git man page?  It used in\ntoo many places that it's probably not worth it to rip it out, but I\ncan tell you that for someone who is learning git from the ground up,\nit would be easier if we used some term like <tree_specifier> instead\nof <tree-ish>.  \n\nRegards,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"35761","messageId":"Pine.LNX.4.64.0702271905200.12485@woody.linux-foundation.org","threadId":"7004","inReplyTo":"E1HMETh-0004BO-Lw@candygram.thunk.org","subject":"Re: Questions about git-rev-parse","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-28T03:19:54Z","receivedAt":"2007-02-28T03:19:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 27 Feb 2007, Theodore Ts'o wrote:\n> \n> So I was looking at git-rev-parse trying to understand the man page, as\n> I was trying to understand how various commands can accept lists (or\n> ranges) of commits, and the man page raised a number of questions.\n> First of all, the DESCRIPTION section doesn't quite parse as English:\n> \n>        Many  git  porcelainish commands take mixture of flags (i.e. parameters\n>        that  begin  with  a  dash  -)  and  parameters  meant  for  underlying\n>        git-rev-list  command  they use internally and flags and parameters for\n>        other commands they use as the downstream of git-rev-list. \n> \n> But, as best as I can gather that it's a helper function meant to do\n> some basic options parsing for those git porcelain commands that expect\n> to take a set of revision ID's.\n\nHeh. This is totally due to hysterical raisins.\n\nIt literally used to be the case that \"git-rev-parse\" (the command) would \nbe used to just parse the command line, and do three different things:\n\n - split \"revision flags\" from \"command flags\"\n\n   For example, \"--before=<date>\" is a revision flag, but \"-r\" (for \n   \"recursive\") would be the command-specific flag for doing a diff.\n\n   git-rev-parse was what knew about all the revision parsing flags (and \n   anything that wasn't a revision parsing flag was by definition a \n   subcommand flag). \n\n   It would also actually parse the date itself, and turn a human-readable \n   date like \"--before=24.hours.ago\" into a git-internal date as seconds \n   since the epoch - so no other git command would ever need to even know.\n\n - split pathnames from either revision flags _or_ command flags\n\n - do all the SHA1 arithmetic parsing for revision names, and split \n   revision names from pathnames and flags.\n\nI think to really appreciate the whole scripting basis of very early git \nversions, do this:\n\n\tgit show v0.99:git-diff-script\n\nor look at the top few lines of the slightly more complex:\n\n\tgit show v0.99.9:git-diff.sh\n\nwhich starts out with:\n\n\trev=$(git-rev-parse --revs-only --no-flags --sq \"$@\") || exit\n\tflags=$(git-rev-parse --no-revs --flags --sq \"$@\")\n\tfiles=$(git-rev-parse --no-revs --no-flags --sq \"$@\")\n\nto parse out all the arguments using \"git-rev-parse\".\n\nNow, all the argument parsing was made internal to all the common git \nprograms, and there really is no reason to use git-rev-parse any more \n(unless you actually want to see the SHA1 of some revision expression), \nbut some of the documentation seems to still be based on that old \nbehaviour, where \"git-rev-parse\" was really a very integral part of \nparsing the git command line.\n\nYou can still see it: try something like\n\n\tgit-rev-parse --since=24.hours.ago --default HEAD\n\nand  you'll see how it parses the command line and turns it into a more \nprimitive form ;)\n\n> This raises some additional questions, though.  If the goal of this\n> command is to parse out those options and arguments which are meant for\n> git-rev-list, why does it translate tag names to SHA id's:\n> \n> % git-rev-parse v1.5.0..v1.5.0.1\n> dedb0faa48787839dbc47b7ca2507bda5924ec2c\n> ^6db027ffe03210324939b3dd655c4223ca023b45\n> \n> After all, git-rev-list can just as easily accept:\n\ngit-rev-list can accept it _now_, but originally, all the low-level \nplumbing commands took only the raw hex representations, and git-rev-parse \nwas literally the thing that made it all \"look\" user-friendly.\n\nSoftware archeology indeed..\n\n\t\tLinus\n"},{"id":"35763","messageId":"Pine.LNX.4.64.0702271921110.12485@woody.linux-foundation.org","threadId":"7004","inReplyTo":"20070228025258.GD2178@thunk.org","subject":"Re: Questions about git-rev-parse","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-28T03:33:03Z","receivedAt":"2007-02-28T03:33:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 27 Feb 2007, Theodore Tso wrote:\n> \n> So while I'm asking questions, where did the \"*-ish\" terminology come \n> from, anyway?\n\nIt's means \"approximate\" or \"having the character of\". Quite like the \nnormal English meaning of \"thirtyish\" or \"fortyish\" when you talk about \napproximate ages of people, or \"tallish\" when you talk about height. \nGoogle for \"ish suffix\", and you'll get as your first hit:\n\n\thttp://www.randomhouse.com/wotd/index.pperl?date=19990617\n\nand the git usage is actually just a variation of that.\n\nSo a \"tree-ish\" is not necessarily exactly a tree, but it has all the \ncharacteristics of a tree (by virtue of there being a well-defined 1:1 \nrelationship with a tree).\n\n> I had the mental model (which I had intuited, since no git documentation \n> I could find had bothered to explain it) that -ish meant something like \n> specifier, so \"tree-ish\" meant tree specifier, so a commit id could get \n> dereferenced into a tree id, so it could be used to specify a tree.\n\nNo, it really is English. At least grammatically.\n\nA \"tree-ish\" is \"like a tree\", exactly like \"sheepish\" is \"like a sheep\". \nNothing really git-specific about it, except for it certainly having \nbecome common usage in a way that it may not be normally ;)\n\n\t\tLinus\n"},{"id":"35780","messageId":"20070228064036.GF2178@thunk.org","threadId":"7004","inReplyTo":"Pine.LNX.4.64.0702271921110.12485@woody.linux-foundation.org","subject":"Re: Questions about git-rev-parse","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-28T06:40:36Z","receivedAt":"2007-02-28T06:40:36Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Feb 27, 2007 at 07:33:03PM -0800, Linus Torvalds wrote:\n> No, it really is English. At least grammatically.\n> \n> A \"tree-ish\" is \"like a tree\", exactly like \"sheepish\" is \"like a sheep\". \n> Nothing really git-specific about it, except for it certainly having \n> become common usage in a way that it may not be normally ;)\n\nWell, in the randomhouse web page you quoted:\n\n\tOur -ish is a suffix that forms adjectives from nouns or other\n\tadjectives. Some of the senses existed in Old English (then\n\tspelled -isc but pronounced the same way), such as 'of, being,\n\tor pertaining to', used to form adjectives indicating a\n\tnational, ethnic, or religious origin (British, Jewish).\n\nit claims that the -ish suffix forms an _adjective_.   But in the sense of\n\n\tgit describe <committish>\n\nIn the git world we are using \"committish\" (and in the documentation\nsometimes we use committish and treeish, and other times we use\ncommit-ish and tree-ish) as a _noun_, and not an adjective.  So I'm\nstill going to take a bit of issue that it's grammatical English, and\nI still think that \"tree_specifier\" and \"commit_specifier\" would have\nbeen clearer.\n\nIn any case, I note that in the git(7) man page, there is a formal\ndefinition of tree-ish, but not of commit-ish.  Would this patch to\nDocumentation/git.txt be correct?\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 9a74747..ff693c3 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -241,6 +241,12 @@ Identifier Terminology\n \toperate on a <tree> object but automatically dereferences\n \t<commit> and <tag> objects that point at a <tree>.\n \n+<commit-ish>::\n+\tIndicates a commit or tag object name.  A\n+\tcommand that takes a <commit-ish> argument ultimately wants to\n+\toperate on a <commit> object but automatically dereferences\n+\t<tag> objects that point at a <commit>.\n+\n <type>::\n \tIndicates that an object type is required.\n \tCurrently one of: `blob`, `tree`, `commit`, or `tag`.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"35787","messageId":"200702280854.32440.andyparkins@gmail.com","threadId":"7004","inReplyTo":"Pine.LNX.4.64.0702271921110.12485@woody.linux-foundation.org","subject":"Re: Questions about git-rev-parse","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-28T08:54:32Z","receivedAt":"2007-02-28T08:54:32Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 February 28 03:33, Linus Torvalds wrote:\n\n> So a \"tree-ish\" is not necessarily exactly a tree, but it has all the\n> characteristics of a tree (by virtue of there being a well-defined 1:1\n> relationship with a tree).\n\nFunny; I'd always guessed that it came from Lord of the Rings, which (I think) \noften mentioned \"Ent-ish\" as being the language of the trees.  Then the happy \ncoincidence of the English idiom usage meaning \"approximately\" was just a \nhappy bonus.\n\nShocking: something geeky that didn't have an association with Lord of the \nRings.  What will they think of next? :-)\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35833","messageId":"Pine.LNX.4.64.0702280751000.12485@woody.linux-foundation.org","threadId":"7004","inReplyTo":"200702280854.32440.andyparkins@gmail.com","subject":"Re: Questions about git-rev-parse","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-28T16:00:32Z","receivedAt":"2007-02-28T16:00:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 28 Feb 2007, Andy Parkins wrote:\n> \n> Funny; I'd always guessed that it came from Lord of the Rings, which (I think) \n> often mentioned \"Ent-ish\" as being the language of the trees.\n\nYeah, we for a while had that overly geekish thing, but we didn't use \n\"entish\", we used just \"ent\". Because an \"ent\" is \"tree-ish\".\n\nSo when we used \"ent\", we didn't have the \"-ish\" there at all, and at some \npoint all the ents got search-and-replaced into \"tree-ish\".\n\nBut \"treeish\" actually came before, and the \"ent\" thing was just a \ntemporary pun that got dropped.\n\nLooking at the git log, the first time we use \"tree-ish\" is fairly early: \napparently May 5, 2005. Commit ac4e0869 introduces it instead of \n<tree/commit> (probably because the tag part got added, and to explain \nthat we only care about the resulting tree and won't actually *use* any \nof the commit/tag information except to get to it).\n\n\t\t\tLinus\n"},{"id":"35912","messageId":"a51a02b80702281816j1ff9d42i5fc680752c515082@mail.gmail.com","threadId":"7004","inReplyTo":"Pine.LNX.4.64.0702271905200.12485@woody.linux-foundation.org","subject":"Re: Questions about git-rev-parse","fromName":"Willhelm Busch","fromEmail":"willhelm.busch@gmail.com","sentAt":"2007-03-01T02:16:09Z","receivedAt":"2007-03-01T02:16:09Z","isPatch":false,"sender":{"key":"willhelm.busch@gmail.com","avatar":null},"body":"On Tue, Feb 27, 2007 at 07:19:54PM -0800, Linus Torvalds wrote:\n> On Tue, 27 Feb 2007, Theodore Ts'o wrote:\n> >\n> > So I was looking at git-rev-parse trying to understand the man page, as\n> > I was trying to understand how various commands can accept lists (or\n> > ranges) of commits, and the man page raised a number of questions.\n> > First of all, the DESCRIPTION section doesn't quite parse as English:\n> >\n> >        Many  git  porcelainish commands take mixture of flags (i.e. parameters\n> >        that  begin  with  a  dash  -)  and  parameters  meant  for  underlying\n> >        git-rev-list  command  they use internally and flags and parameters for\n> >        other commands they use as the downstream of git-rev-list.\n> >\n> > But, as best as I can gather that it's a helper function meant to do\n> > some basic options parsing for those git porcelain commands that expect\n> > to take a set of revision ID's.\n>\n> Heh. This is totally due to hysterical raisins.\n\nWhen it comes to dancing time\n At the branch of the grapevine\nOut pop many lively souls,\n From their seed pods, shells, and holes.\n\n'Twas one balmy summer's night\n When some documents to write\nLinus rested on the ground\n Near the dancers' cheery round.\n\nHeedless of their drunken rages,\n He cranked out a few man pages,\nAs he started git-rev-parse,\n Came a merry nighttime farce.\n\nWhen by wine they are made merry\n Certain fruits wax literary,\nWriting nonsense as they please --\n Raisins are the worst of these.\n\nThey seized Linus as their chance.\n \"Let us leave this odious dance!\"\nWith a hysterical hop,\n Down they jumped, to his laptop!\n\nAs they made a small edit,\n Typed the raisins: \"git commit\"!\n\"Could my shell prompt be possessed?\"\n Linus wondered, much distressed.\n\nLinus scratched his Nordic pate.\n \"I should not be up this late!\nCoffee's addling my sight!\n Better finish for tonight.\"\n\nIn the main I'm laudatory\n Of the git repository.\nIt has weirdness and to spare,\n But the raisins put it there.\n"}]}