Hi,
I noticed this while writing a small script for myself:
$ git rev-parse --verify --quiet '@{u}'
fatal: No upstream configured for branch 'local'
The functions that get run when rev-parse does its thing all return a
pointer to a strbuf, return the length of the modified buf or something
to that effect. However get_upstream_branch() calls die() which writes
to stderr unconditionally.
Call hierarchy in the above case:
die()
get_upstream_branch()
interpret_upstream_mark()
interpret_branch_name()
substitute_branch_name()
dwim_ref()
get_sha1_basic()
get_sha1_1()
get_sha1_with_context_1()
get_sha1_with_context()
get_sha1()
cmd_rev_parse()
Passing quiet = 1 all the way down I assume isn't feasible. Changing
get_upstream_branch() to not die but rather signify an error could work.
But interpret_branch_name() has four different callers belonging to
different parts of Git.
I marked this as "maybe" because I guess it's fair to say that rev-parse
'@{u}' is not the correct way to check whether a branch as a configured
upstream. Furthermore even if it writes to stderr the exit status is
still non-zero so the only way to get bitten by this is if you doing
something like:
foo=$(git rev-parse --verify --quiet $bar 2>&1) # pointless redirection
*and* you check whether the exit code is equal to 1, not unequal to zero.
On the other hand, it does break the expectations that the documentation
and the other uses of git rev-parse one encounters give. At least for
me. It should be able to verify that $foo is valid, and it should do so
quietly.
On a related note:
$ git branch origin/master
$ git rev-parse --verify --quiet origin/master
warning: refname 'origin/master' is ambiguous.
7c07808349fd0fc2c61a169833eeb55163cf3df4
Best regards,
Øsse
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html