on MacOS it shows internal error on gws ff

[marcofranssen]

On MacOS the following output occurs when running gws ff.

gws ff
devtools/diagram-generator:
    master :          Internal error
devtools/docker:
    master :          Internal error
devtools/welcome-team:
    master :          Internal error
k8s/kube-ci:
    master :          Internal error
k8s/kube-system:
    master :          Internal error
k8s/kube-vnext:
    master :          Internal error (fast-forwarded)
vnext/customer/api:
    feature/new-cqrs-… : Internal error (fast-forwarded)
    master :               Internal error
vnext/customer/domain:
    master :          Internal error
vnext/customer/es-indexer:
    master :          Internal error (fast-forwarded)
vnext/customer/list:
    master :          Internal error (fast-forwarded)
vnext/customer/search-widget:
    master :          Internal error (fast-forwarded)
vnext/customer/ui:
    master :          Internal error (fast-forwarded)
vnext/react/loginform:
    master :          Internal error
vnext/react/ui-elements:
    master :          Internal error (fast-forwarded)

[soifou]

I have the same problem (macOS 10.12.6, bash 4.4.12).

I looked into the code and I think I found the culprit. When fetching the revision in git_check_branch_origin() function, the branch name is interpreted with its ANSI color codes.

git rev-parse --verify \E[7;33mmaster\E[m

instead of

git rev-parse --verify master

An ugly fix would be to escape the colors sequence to fetch only the raw branch name:

function git_check_branch_origin()
{
  ...

    branch=$2
    # macOS only - Remove ANSI color codes to get the raw branch name
    if [[ `uname` == "Darwin" ]]; then
        branch=$(echo $2 | sed -E "s/"$'\E'"\[([0-9]{1,2}(;[0-9]{1,2})*)?m//g")
    fi

    # Git commands to execute
    local_cmd=( "git" "rev-parse" "--verify" "$branch" )
    remote_cmd=( "git" "rev-parse" "--verify" "${GIT_ORIGIN}/$branch" )

  ...
}

I don't know why Bash on macOS is reacting differently than it's Linux version (I have the same version on Debian 8) but it is.

Maybe it's better to not colorize the branch name in order to avoid this fix... Any idea @emlun ?

[emlun]

Sorry I've been slow to respond to this... Thanks @marcofranssen for the report and @soifou for the detailed additional info!

It does indeed seem weird that that should happen, and we do indeed not want to work with colorized branch names internally. I think explicitly setting --no-color in git_branches function should do it.

[emlun]

@marcofranssen Does eac68e3 on the issue-34 branch work better?

[soifou]

I answer for him.

This commit fix the "Internal error" thing but you have to add the --no-color param also in git_branch() l. 558. Without it, It adds an extra clean branch line for those in dirty state.

Current

docker:
    master :        Dirty (Untracked files)
docker/github/composer:
    master :        Internal error

Param --no-color in git_branches() only

docker:
    master :        Dirty (Untracked files)
    master :                  Clean
docker/github/composer:
    master :                  Clean

Param --no-color in git_branches() and git_branch()

docker:
    master :                  Dirty (Untracked files)
docker/github/composer:
    master :                  Clean

And last but not least we loose the current branch indicator... but I can live without it.

[marcofranssen]

I can confirm it resolves the issue on Mac. On Windows it still looks to be the same and still works.

[emlun]

Gotcha, I've taken inventory and added --no-color to all git branch commands. This will be included in the next release, which I hope to make in the coming few days.

And last but not least we loose the current branch indicator... but I can live without it.

Did gws ever have a current branch indicator?