Handle slashes in branch name when shortening remote

[NAR8789]

PR Main Content

Bugfix: When the branch name contains slashes, setting ZSH_GIT_PROMPT_SHOW_UPSTREAM=2 did not produce the expected behavior of upstream name getting shortened.

For example, with my current branch name of fix/handle-slashes-in-branch-name, and an upstream of origin/fix/handle-slashes-in-branch-name, I'd expect a prompt like

[fix/handle-slashes-in-branch-name {origin}|✔]

but I was actually seeing

[fix/handle-slashes-in-branch-name {origin/fix/handle-slashes-in-branch-name}|✔]

Root cause: original shortening process split on slashes and tried to match last component to branch name. Due to splitting on slashes, last component would be a suffix of branch name, and would not match.

Fix: Use suffix removal instead of splitting on slashes.

Extra Bits

I've also added tests for the shell code, and made a minor fix to make flake8 pass. These are not technically part of the above, so I can pull these into separate PRs if you prefer.

Tests

I've brought in shunit2 to test the zsh parts.

In the individual tests, I've written expectations using the fully-rendered version of the prompt, complete with ANSI sequences. This renders nicely if you cat or less -R the file, but as far as I know all text editors will render the ANSI control chars as garbage.

I decided to include the ANSI garbage because git_super_status already outputs ANSI codes even before prompt escapes get interpreted, so to some degree having garbagy expect strings is unavoidable. Going with fully rendered strings means they at least display nicely in less -R

Flake8 Fix

Flake8 3.6.0 does not like line breaks anywhere around operators. This is causing travis builds to always fail. Since W504 is the current recommendation. I've disabled W503.

Background

I tend to have slashes in my branch names at work, because we use a convention of prefixing feature branches with feature/, and fixes with hotfix/.