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

If there's a branch (either local or remote) called 'HEAD' commands that take a ref currently emits a warning, no matter if the output is going to a TTY or not.

Fix this by making sure we only output this warning when stderr is a TTY. Other git commands or scripts should not care about this ambiguity.

This fix prevents gitk from barfing when given no arguments and there's a branch called 'HEAD'.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>

---

In 2f8acdb ('core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.'), a check for collisions of refs was introduced. It does not seem to me like the intention was to check HEAD for ambiguty (because the commit talks about branches and tags), but it does.

Because HEAD cannot be disambiguated like branches and tags can, this can lead to an annoying warning, or even an error in the case of gitk.

A branch called HEAD can be 'injected' into another user's repo through remotes, and this can cause annoyance (and in the case of gitk, brokenness) just by pulling the wrong remote. Yuck.

The particular problem of gitk can be fixed by making gitk able to parse the warning, and probably forwarding it to the user. This strikes me as The Right Thing To Do(tm), but is outside of my gitk and TCL/TK skills.

Alternatively, gitk could state that it doesn't care about ambiguous refs, by calling 'git -c core.warnambiguousrefs=0 show-ref <ref>'.

One question is if ANY warnings should be output to stderr if it's not a TTY. My guess is that there probably are some classes of warnings that should, but the vast majority should probably not.

Perhaps it's better to make warning() filter the output if stderr is not a tty instead, and make the places that needs to warn just do fprintf(stderr, ...) instead? That's one huge hammer, though.

Another question is if we should come up with a way of disambiguating HEAD. Perhaps having something like 'refs/HEAD' will do?

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

I think 3) + 5) might be the most sane solution. That way we inform the user that there's an ambiguity if he or she runs 'gitk HEAD' (so he or she has a chance the chance to correct it), but the correct HEAD is chosen (without any annoying warnings) if the user didn't specify a ref.

This combination also relies on us NOT doing 1), 2) or 4); i.e the warning must still be output to reach the user.

Thoughs?

 sha1_name.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)