From: Junio C Hamano Date: Mon, 09 May 2011 16:33:07 GMT Subject: Re: [PATCH] only warn about ambiguous refs if stderr is a tty Message-ID: <7vmxivq1fg.fsf@alter.siamese.dyndns.org> In-Reply-To: <20110509124931.GA18197@sigill.intra.peff.net> Jeff King writes: > 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? >> 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