Re: [PATCH] only warn about ambiguous refs if stderr is a tty

Jeff King [off-list ref] 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.
...

quoted

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?

quoted

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

On Mon, May 09, 2011 at 09:33:07AM -0700, Junio C Hamano wrote:

quoted

quoted

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?
[...]

quoted

quoted

 3) Make gitk understand and forward warnings to the user

Yeah, I think so. Now we just need a volunteer who wants to write some
tcl.  :)

-Peff