Junio C Hamano [off-list ref] writes:
I would suspect that this may be fine.
"rev-parse --verify" makes sure the named object exists, but in this
case @{u} does not even name any object, does it?
Hmph, but "rev-parse --verify no-such-branch" does *not* name any
object, we would want to see it barf, and we probably would want to
be able to squelch the message. So it is unclear if @{u} barfing is
a good idea.
What is the reason why it is inpractical to pass 'quiet' down the
callchain?
Junio C Hamano <gitster <at> pobox.com> writes:
Junio C Hamano <gitster <at> pobox.com> writes:
quoted
I would suspect that this may be fine.
"rev-parse --verify" makes sure the named object exists, but in this
case <at> {u} does not even name any object, does it?
Hmph, but "rev-parse --verify no-such-branch" does *not* name any
object, we would want to see it barf, and we probably would want to
be able to squelch the message. So it is unclear if <at> {u} barfing is
a good idea.
That was my counter-argument :) The "vibe" I get from rev-parse --verify
--quiet is that it should handle anything.
What is the reason why it is inpractical to pass 'quiet' down the
callchain?
Maybe I'm missing something obvious, but wouldn't that mean changing the
signature of 9 different functions, and consequently all of their calls
throughout Git?
That's perhaps not a good argument. Who cares whether a diff is small or
large if it fixes a bug properly? But most (or all) of those functions
do not concern themselves with printing stuff so maybe an additional
"quiet?" argument would look foreign in most places and make the code
harder to read.
Øsse