{"thread":{"id":"40565","subject":"about rev-parse's quietness","startedAt":"2015-10-15T10:26:34Z","lastAt":"2015-10-15T19:59:27Z","messageCount":2,"participants":["stefan.naewe@atlas-elektronik.com","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"271725","messageId":"561F7F5A.4060708@atlas-elektronik.com","threadId":"40565","inReplyTo":null,"subject":"about rev-parse's quietness","fromName":"","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2015-10-15T10:26:34Z","receivedAt":"2015-10-15T10:26:34Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"Hello there.\n\nI'm using a bash function that does a combination of 'ls -l', 'git status', and 'git branch'\nto give me a quick overview of where I stand in the current git repo.\n\nI planned to extend that function to also list the to-be-pushed commits in the\ncurrent branch, something like \n\n$ git log --oneline --abbrev-commit --decorate @{u}..\n\nBut I don't want to run that 'git log...' if there's no upstream configured\nfor HEAD (and I don't want to see any error!)\n\nOK. That's a task for 'git rev-parse' I thought:\n\n$ up=$(git rev-parse --verify --quiet @{u}) &&\n  git log --left-right --oneline --abbrev-commit --decorate $up\nfatal: no upstream configured for branch 'master'\n\nWait. What?\n\nI thought rev-parse with '--verify' and '--quiet' is just that - quiet -\nin case \"...the first argument is not a valid object name\" ?\n\nLet's see:\n$ git rev-parse --verify --quiet master@{xyz} || echo No\nNo\n\n$ git rev-parse --verify --quiet master@{u} || echo No\nfatal: no upstream configured for branch 'master'\nNo\n\nI don't want to see that error (and I know I could just redirect stdout/stderr to /dev/null ...)\n\nSo: Are my expectations about 'rev-parse --verify --quiet' wrong or am I doing\nsomething stupid ?\n\nThanks,\n  Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: Disclaimer: Written by a highly caffeinated mammal.\npython -c \"print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')\" \nGPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF\n"},{"id":"271774","messageId":"xmqqk2qnhpi8.fsf@gitster.mtv.corp.google.com","threadId":"40565","inReplyTo":"561F7F5A.4060708@atlas-elektronik.com","subject":"Re: about rev-parse's quietness","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-15T19:59:27Z","receivedAt":"2015-10-15T19:59:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"<stefan.naewe@atlas-elektronik.com> writes:\n\n> Let's see:\n> $ git rev-parse --verify --quiet master@{xyz} || echo No\n> No\n>\n> $ git rev-parse --verify --quiet master@{u} || echo No\n> fatal: no upstream configured for branch 'master'\n> No\n\nYup, that is unfortunate.  The above two pass different codepaths in\nsha1_name.c::get_sha1_basic().\n\n * The code first notices \"master@{anything}\" has @{anything}\n   suffix, which could be @{123} (counted reflog), @{1.hour.ago}\n   (timed reflog), @{-1} (prior checkout---valid only when nothing\n   comes before \"@{...}\") or @{upstream}/@{push}.\n\n * The first two goes through dwim_log(), together with\n   'master@{xyz}' to locate the reflog of 'master' (i.e. what comes\n   before that @{anything}) and identifies that we need to look at\n   the log for 'refs/heads/master', looks up an appropriate entry,\n   and the processing ends there, returning success.  However, 'xyz'\n   is not a valid specification for either counted or timed reflog,\n   so the function returns failure for 'master@{xyz}', letting the\n   remainder of the callchain to take care of it.\n \n * The third one goes to interpret_nth_prior_checkout() and the\n   processing ends there, returning success.\n\n * The last one goes to dwim_ref(), together with just 'master'\n   without any @{anything}.  It tries to turn master@{upstream} or\n   master@{push} to refs/remotes/origin/master and then it is used\n   to grab the object name pointed by it.\n\nThe helper function dwim_ref() calls to turn master@{upstream} to\nrefs/remotes/origin/master, interpret_branch_name(), is designed to\ndie() when fed a ref without upstream (or @{push} when there is no\nsuch thing).\n\nNaively, one would imagine that the die() can be demoted to an\ninternal error return to the caller (just like 'master@{xyz}' is\nrejected silently in the dwim_log() codepath) and everything else\nshould go well.  It is unfortunately not sufficient, though, as the\nother callers to interpret_branch_name() rely on the function to\ndie and are not prepared to show the error messages themselves.\n\nSo I think this is fixable and the right approach to fix it is as\nhinted above, i.e.\n\n * audit callers of interpret_branch_name() and find the ones that\n   depend on the function to die (i.e. it does not handle the case\n   where interpret_branch_name() notices that 'master@{upstream}'\n   does not exist).  Change them to die with an appropriate message\n   themselves.\n\n * change interpret_branch_mark(), which is actually where the die()\n   happens, so that it can notice a request to use 'master@{upstream}' \n   when there is no such upstream and signal an error to the caller.\n\nI am not saying that you should be the one to fix it, though ;-) The\nabove is to help those who may be interested to look into the codepath\nto do so.\n\nThanks.\n"}]}