Fix list_has_remote()

[RichiH]

Closes #305

[alerque]

This implementation surprised me a little, but I can't come up with anything better and I can't find a reason this won't work so...

[RichiH]

I couldn't find anything else that doesn't require you to know the name of the remote and/or branch beforehand... I agree that it smells weird, but it should be pretty robust. I will add a comment before merging.

[alerque]

The git remote porcelain command lists remotes too without knowing their names. That's what I usually use, I'm not sure if there is a better plumbing command or if there are any benefits/drawbacks over checking for the config directory.

Either way both these solutions only tell us if the repo has a remote, not if the branch we are on has a remote tracking branch.

[RichiH]

Heh, yes. git remote, woods for the trees, etc...

https://stackoverflow.com/a/9753364 lead me to git for-each-ref --format='%(upstream:short)' "$(git symbolic-ref -q HEAD)"

[alerque]

I like the looks of that last one much more, and it confirms not just that we have a remote but that the current branch has a tracking branch setup on the remote. I think that's the info we really wanted to confirm in the first place.

[RichiH]

Thanks for the challenge on git remote!

Generally speaking, I vastly prefer to go through commands, not files, at least if they are reasonably old. That way, we benefit from future cleanups, protections, etc in upstream Git.

Unfortunately, 'empty' does still output return code 0 so we will need to go -n.

[RichiH]

@alerque I created #305 just to have something to actually fix and point to. As cbfd1ff is not in any tags, we don't need to add anything to the changelog but it still felt cleaner.

Once this PR is merged, we should cut an RC. Not because we would release this precise version, but to trigger users into testing.