Re: [PATCH] only warn about ambiguous refs if stderr is a tty
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 9, 2011, 16:33 UTC
- Message-ID
- <7vmxivq1fg.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20110509124931.GA18197@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 9 quoted lines
> Thinking on it more, I think warning is probably the only sane thing to > do there. Having a branch with that name is just going to be confusing > in the long run, and the sooner we start making the user aware of the > situation, the better. > ... >> I think having the ambiguity warning in itself isn't the problem, it's >> gitk not swallowing it that is. > > Agreed.
I agree with both of the above. It seems that the only thing we would need is to do (3) and nothing else in Erik's original list?
Show 11 quoted lines
>> So, to recap: The way I see it, these are our options: >> >> 1) Discard this specific warning when stderr isn't a TTY (i.e >> what this patch does) >> 2) Discard all warnings when stderr isn't a TTY >> 3) Make gitk understand and forward warnings to the user >> 4) Have gitk explicitly ignore ambiuous refs >> 5) Come up with a way to disambiguate HEAD, and use that instead >> by default >> 6) Force HEAD to never be ambiguous >> 7) Leave things as they are