GitLab

check_output() in get_tagname_or_hash() returns bytes instead of str in
python3.  Decode the return value to utf-8, this works in both python2
and python3.
Co-authored-by: Stimim Chen <stimim@google.com>

Fix the finicky parsing logic and just ask git the necessary information
directly.

The previous version modified the whole environment leading to
problems (see #7757). This version *adds* LANG=C to the current
env, without overriding it completely.

Fixes #7757.

As described in #6086 there will be an error when one set another
language than English.

When a commit has multiple tags associated to it, the git-prompt will
throw the following error:

git_super_status:[:4: integer expression expected: v0.21.x\ntags/v0.21.5,
git_super_status:[:7: integer expression expected: origin/v0.21.x,
git_super_status:[:11: integer expression expected: origin/v0.21.x,
git_super_status:[:14: integer expression expected: v0.21.x
git_super_status:[:23: integer expression expected: v0.21.x

This is due to the prompt expecting the tag field to be a single word
with no spaces in between but if there are multiple tags the python
script returns a string with ', ' space separated list of tags.
This throws off the parser. The solution is to ensure that the python
script returns a space-less string ensuring the git-prompt parser to
properly parse the data.
Signed-off-by: Thanh Ha <zxiiro@linux.com>

Inside a fresh git repo, i.e. immediately after a `git init`, usually no
commit template exists yet. In this case, git renders a different
status message than "Initial commit on". We should consider this message
when attempting to parse out the branch name.

Fixes #6301

This commit uses the `git status --porcelain -b` format to gather the
number of ahead and behind commits related to the remote branch.

This version uses `git status --porcelain` instead of making
multiple calls to `git status`.

"/usr/bin/python2" does not exist on Mac OSX (see #2382), so fuck people who have
"python" symlinked to "python3"

This reverts commit e5ed07e2

as suggested in #2382

In Python3 without universal_newlines set to True
output from Popen was byte-encoded.