Jeff King <peff@xxxxxxxx> 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 -- 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