{"thread":{"id":"23657","subject":"rev-parse vs. rev-list --no-walk","startedAt":"2010-05-01T18:35:29Z","lastAt":"2010-05-03T15:50:19Z","messageCount":4,"participants":["Michael J Gruber","Junio C Hamano","Jay Soffian"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140700","messageId":"4BDC7471.9030107@drmicha.warpmail.net","threadId":"23657","inReplyTo":null,"subject":"rev-parse vs. rev-list --no-walk","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-01T18:35:29Z","receivedAt":"2010-05-01T18:35:29Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"In connection with an upcoming RFD patch, I noticed that rev-parse and\nrev-list --no-walk do very similar things (OK - I knew *that* already)\nin different ways. In particular, rev-list uses the ordinary\nsetup_revision() which is used in many other places, whereas rev-parse\ndoes it's own thing.\n\nrev-parse does a couple more things, of course, but why doesn't it use\nsetup_revision() ? I just wanted to ask before trying to restructure\nthings....\n\nAs it is we have the maintenance burden of keeping both rev option\nparsers in sync. And, in fact, they are not:\n\n- setup_revision() (and thus rev-list) explicitly adds HEAD for \"--all\",\nrev-parse does not\n\n- setup_revision() outputs each sha1 only once, rev-parse possibly\nmultiple times (in case of coinciding heads/tags...)\n\nOf course, rev-parse and rev-list --no-walk do actually very different\nthings, as one can see from the results of \"--tags\" on both (partially\nanswering my own question here). And that difference is intentional. So:\n\n- Should setup_revision() really add HEAD on --all? (Probably yes.) In\nthis case I'd adjust the doc.\n\n- Shouldn't rev-parse --all add HEAD as well?\n\n- Is there any way to use setup_revision() without resolving tags to\ncommits etc. (and thus using it for rev-parse)?\n\nMichael\n"},{"id":"140712","messageId":"7v1vdv4ccz.fsf@alter.siamese.dyndns.org","threadId":"23657","inReplyTo":"4BDC7471.9030107@drmicha.warpmail.net","subject":"Re: rev-parse vs. rev-list --no-walk","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-01T20:05:00Z","receivedAt":"2010-05-01T20:05:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> rev-parse does a couple more things, of course, but why doesn't it use\n> setup_revision() ? I just wanted to ask before trying to restructure\n> things....\n\nBecause rev-parse was written as a helper for scripts that take revision\noptions and non-revision options, whose purpose was to sift the arguments\ninto four bins:\n\n    - revision parameters       (e.g. HEAD, master~20)\n    - revision flags\t\t(e.g. --all, --parents)\n    - non-revision parameters\t(e.g. Makefile, hello.c)\n    - non-revision flags\t(e.g. --stat, -p)\n\nas its primary customer was things like whatchanged that used to be\nscripted this way:\n\n\tgit rev-list rev-flags rev-params |\n        git diff-tree --stdin non-rev-flags non-rev-params |\n        less\n\nIf you call setup_revisions(), it will call handle_revision_opt() which in\nturn will call diff_opt_parse(), so I suspect you wouldn't be able to sift\nbetween rev-flags and non-rev-flags.\n\nI think one sane thing to do is to stop adding new rev-flags revision.c\nsupports to rev-parse (it already lags behind and nobody complained that\nrev-parse doesn't understand --first-parent as a rev-flag), and keep its\nuse as \"revision and non revision option sifter\" only to support older\nscripts written back in v1.0.0 days.  Its primary use these days is \"turn\nsymbolic object names into 40-letter SHA-1\", but \"option sifter\" aspect of\nthe command seems to have outlived its usefulness.\n"},{"id":"140831","messageId":"t2z76718491005030822l469c720ag1466ecd2bad31f32@mail.gmail.com","threadId":"23657","inReplyTo":"7v1vdv4ccz.fsf@alter.siamese.dyndns.org","subject":"Re: rev-parse vs. rev-list --no-walk","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-05-03T15:22:40Z","receivedAt":"2010-05-03T15:22:40Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sat, May 1, 2010 at 4:05 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> I think one sane thing to do is to stop adding new rev-flags revision.c\n> supports to rev-parse (it already lags behind and nobody complained that\n> rev-parse doesn't understand --first-parent as a rev-flag), and keep its\n> use as \"revision and non revision option sifter\" only to support older\n> scripts written back in v1.0.0 days.  Its primary use these days is \"turn\n> symbolic object names into 40-letter SHA-1\", but \"option sifter\" aspect of\n> the command seems to have outlived its usefulness.\n\nWe tell scripters to be careful to use the plumbing and not the\nporcelain. From that standpoint, shouldn't we do our best to prevent\nthe plumbing from falling into disrepair?\n\n(Or perhaps I'm reading too much into what you say.)\n\nj.\n"},{"id":"140832","messageId":"4BDEF0BB.6080009@drmicha.warpmail.net","threadId":"23657","inReplyTo":"t2z76718491005030822l469c720ag1466ecd2bad31f32@mail.gmail.com","subject":"Re: rev-parse vs. rev-list --no-walk","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-03T15:50:19Z","receivedAt":"2010-05-03T15:50:19Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jay Soffian venit, vidit, dixit 03.05.2010 17:22:\n> On Sat, May 1, 2010 at 4:05 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> I think one sane thing to do is to stop adding new rev-flags revision.c\n>> supports to rev-parse (it already lags behind and nobody complained that\n>> rev-parse doesn't understand --first-parent as a rev-flag), and keep its\n>> use as \"revision and non revision option sifter\" only to support older\n>> scripts written back in v1.0.0 days.  Its primary use these days is \"turn\n>> symbolic object names into 40-letter SHA-1\", but \"option sifter\" aspect of\n>> the command seems to have outlived its usefulness.\n> \n> We tell scripters to be careful to use the plumbing and not the\n> porcelain. From that standpoint, shouldn't we do our best to prevent\n> the plumbing from falling into disrepair?\n\nAccording to git(1), git rev-list is low-level, but git rev-parse is not!\n\n>From a cursory look at current source it would be simple to discourage\nuse of rev-parse for revision flags (and, probably, as an option\nsifter). There's no need to remove them (and break some outside\nscripts). Junio suggested not to add any new ones to rev-parse. That\nwould make my RFD patch (--heads, --locals) smaller, and answers the\nquestions about solving the difference between rev-parse and rev-list\n\"-all\" regarding HEAD. But maybe git-rev-parse(1) should change then, in\norder not to encourage its use as option sifter. Everyone stops by this\nman page when looking up revision syntax.\n\nMichael\n"}]}