# about rev-parse's quietness

2 messages from 2015-10-15 to 2015-10-15. Participants: stefan.naewe@atlas-elektronik.com, Junio C Hamano.
Thread: https://gitlist.dev/t/40565

## stefan.naewe@atlas-elektronik.com, 2015-10-15 10:26

Subject: about rev-parse's quietness
Message-ID: <561F7F5A.4060708@atlas-elektronik.com>
URL: https://gitlist.dev/e/561F7F5A.4060708%40atlas-elektronik.com

```
Hello there.

I'm using a bash function that does a combination of 'ls -l', 'git status', and 'git branch'
to give me a quick overview of where I stand in the current git repo.

I planned to extend that function to also list the to-be-pushed commits in the
current branch, something like 

$ git log --oneline --abbrev-commit --decorate @{u}..

But I don't want to run that 'git log...' if there's no upstream configured
for HEAD (and I don't want to see any error!)

OK. That's a task for 'git rev-parse' I thought:

$ up=$(git rev-parse --verify --quiet @{u}) &&
  git log --left-right --oneline --abbrev-commit --decorate $up
fatal: no upstream configured for branch 'master'

Wait. What?

I thought rev-parse with '--verify' and '--quiet' is just that - quiet -
in case "...the first argument is not a valid object name" ?

Let's see:
$ git rev-parse --verify --quiet master@{xyz} || echo No
No

$ git rev-parse --verify --quiet master@{u} || echo No
fatal: no upstream configured for branch 'master'
No

I don't want to see that error (and I know I could just redirect stdout/stderr to /dev/null ...)

So: Are my expectations about 'rev-parse --verify --quiet' wrong or am I doing
something stupid ?

Thanks,
  Stefan
-- 
----------------------------------------------------------------
/dev/random says: Disclaimer: Written by a highly caffeinated mammal.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')" 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

```

## Junio C Hamano, 2015-10-15 19:59

Subject: Re: about rev-parse's quietness
Message-ID: <xmqqk2qnhpi8.fsf@gitster.mtv.corp.google.com>
URL: https://gitlist.dev/e/xmqqk2qnhpi8.fsf%40gitster.mtv.corp.google.com
In-Reply-To: <561F7F5A.4060708@atlas-elektronik.com>

```
<stefan.naewe@atlas-elektronik.com> writes:

> Let's see:
> $ git rev-parse --verify --quiet master@{xyz} || echo No
> No
>
> $ git rev-parse --verify --quiet master@{u} || echo No
> fatal: no upstream configured for branch 'master'
> No

Yup, that is unfortunate.  The above two pass different codepaths in
sha1_name.c::get_sha1_basic().

 * The code first notices "master@{anything}" has @{anything}
   suffix, which could be @{123} (counted reflog), @{1.hour.ago}
   (timed reflog), @{-1} (prior checkout---valid only when nothing
   comes before "@{...}") or @{upstream}/@{push}.

 * The first two goes through dwim_log(), together with
   'master@{xyz}' to locate the reflog of 'master' (i.e. what comes
   before that @{anything}) and identifies that we need to look at
   the log for 'refs/heads/master', looks up an appropriate entry,
   and the processing ends there, returning success.  However, 'xyz'
   is not a valid specification for either counted or timed reflog,
   so the function returns failure for 'master@{xyz}', letting the
   remainder of the callchain to take care of it.
 
 * The third one goes to interpret_nth_prior_checkout() and the
   processing ends there, returning success.

 * The last one goes to dwim_ref(), together with just 'master'
   without any @{anything}.  It tries to turn master@{upstream} or
   master@{push} to refs/remotes/origin/master and then it is used
   to grab the object name pointed by it.

The helper function dwim_ref() calls to turn master@{upstream} to
refs/remotes/origin/master, interpret_branch_name(), is designed to
die() when fed a ref without upstream (or @{push} when there is no
such thing).

Naively, one would imagine that the die() can be demoted to an
internal error return to the caller (just like 'master@{xyz}' is
rejected silently in the dwim_log() codepath) and everything else
should go well.  It is unfortunately not sufficient, though, as the
other callers to interpret_branch_name() rely on the function to
die and are not prepared to show the error messages themselves.

So I think this is fixable and the right approach to fix it is as
hinted above, i.e.

 * audit callers of interpret_branch_name() and find the ones that
   depend on the function to die (i.e. it does not handle the case
   where interpret_branch_name() notices that 'master@{upstream}'
   does not exist).  Change them to die with an appropriate message
   themselves.

 * change interpret_branch_mark(), which is actually where the die()
   happens, so that it can notice a request to use 'master@{upstream}' 
   when there is no such upstream and signal an error to the caller.

I am not saying that you should be the one to fix it, though ;-) The
above is to help those who may be interested to look into the codepath
to do so.

Thanks.

```