Bash always seems to run slowly because git is used in command line status

[Jademalo]

Issue Type: Bug

I created a new Ubuntu dev container using "Add development container files". After starting the container, I attempted to start a new bash terminal through Terminal->New Terminal.

However, when the terminal loads, there is no output and the process in the list to the right hand side says git. If I Ctrl+C on the terminal window, git closes and I get back to bash. however, as soon as I enter another command, it immediately starts running git again.

I've got no idea what is causing this, and my container currently has no special configuration. it is simply a basic ubuntu container built with the automatic config within VS Code.

Extension version: 0.224.2 VS Code version: Code 1.65.2 (c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1, 2022-03-10T14:33:55.248Z) OS version: Windows_NT x64 10.0.22000 Restricted Mode: No Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz (12 x 4008)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|31.84GB (15.98GB free)| |Process Argv|--crash-reporter-id 75d2bff3-b4ef-4cb2-9b19-e7eeeba2b392| |Screen Reader|no| |VM|0%| |Item|Value| |---|---| |Remote|Dev Container: Ubuntu| |OS|Linux x64 5.10.16.3-microsoft-standard-WSL2| |CPUs|Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz (12 x 4008)| |Memory (System)|15.55GB (12.60GB free)| |VM|0%|

A/B Experiments

``` vsliv368:30146709 vsreu685:30147344 python383cf:30185419 vspor879:30202332 vspor708:30202333 vspor363:30204092 vstes627:30244334 pythonvspyl392:30443607 pythontb:30283811 pythonptprofiler:30281270 vshan820:30294714 vstes263:30335439 vscorecescf:30445987 pythondataviewer:30285071 vscod805:30301674 pythonvspyt200:30340761 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 vsaa593cf:30376535 vsc1dst:30438360 pythonvs932:30410667 wslgetstarted:30449410 vsclayoutctrt:30451275 dsvsc009:30452663 pythonvspyt640:30450904 vscscmwlcmc:30438804 vscgsvid2:30447481 pynewfile477:30450038 ```

[Jademalo]

On further experimentation, it seems to be an issue with specifically opening an existing windows folder in a dev container. For whatever reason, it seems to seriously struggle with running git on the container if it has a mounted windows folder.

I'm not sure why the terminal is running some sort of git command every time there's a new line, but that's causing severe issues trying to use the terminal. Running a container with volume mounted source code seems to not have this problem since git sorts itself out quickly.

[bamurtaugh]

cc @Tyriar

[Tyriar]

There's nothing in VS Code's terminal component that does this, it's either related to installed dotfiles or the container image.

[chrmarti]

@Jademalo Does your dev container (or dotfiles) run any kind of Git integration for the shell? (E.g., does the shell show a Git status?)

[Jademalo]

@chrmarti I'm not entirely sure, I'm just using the standard default ubuntu container that gets set up with VSCode's automatic config. There's a tick or cross next to the shell prompt that I've not seen outside of VSCode before, but I'm not sure what that is. It's possible that it could be doing some sort of git intergration, but it's not something that I've set up.

Here's my current dockerfile and devcontainer.json;

# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.224.2/containers/ubuntu/.devcontainer/base.Dockerfile

# [Choice] Ubuntu version (use hirsuite or bionic on local arm64/Apple Silicon): hirsute, focal, bionic
ARG VARIANT="hirsute"
FROM mcr.microsoft.com/vscode/devcontainers/base:0-${VARIANT}

# [Optional] Uncomment this section to install additional OS packages.
# RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
#     && apt-get -y install --no-install-recommends <your-package-list-here>

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.224.2/containers/ubuntu
{
    "name": "Ubuntu",
    "build": {
        "dockerfile": "Dockerfile",
        // Update 'VARIANT' to pick an Ubuntu version: hirsute, focal, bionic
        // Use hirsute or bionic on local arm64/Apple Silicon.
        "args": { "VARIANT": "focal" }
    },

    // Set *default* container specific settings.json values on container create.
    "settings": {    
        "terminal.integrated.confirmOnExit": "hasChildProcesses",
        "files.associations": {
            "*.inc": "poryscript-asm",
            "*.h": "c",
        },
        "C_Cpp.errorSquiggles": "Enabled",
        "C_Cpp.intelliSenseEngineFallback": "Disabled",

    },

    // Add the IDs of extensions you want installed when the container is created.
    "extensions": [
        "ms-vscode.cpptools",
        "karathan.poryscript",
        "actboy168.tasks",
        "dan-c-underwood.arm",
        "ms-vscode-remote.remote-containers",
        "exelord.git-commits",
        "donjayamanne.githistory"
        ],

    // Use 'forwardPorts' to make a list of ports inside the container available locally.
    // "forwardPorts": [ 2345 ], // mGBA debug port

    // Use 'postCreateCommand' to run commands after the container is created.
    "postCreateCommand": "bash .devcontainer/install-dev-tools.sh",

    "mounts": [
    ],

    // Comment out to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
    "remoteUser": "vscode",
    "features": {
        "golang": "latest"
    }
}

install-dev-tools.sh is just a script that runs sudo apt -y install gcc-arm-none-eabi binutils-arm-none-eabi build-essential libpng-dev libncurses5

[chrmarti]

Do you have a dotfiles repository configured in your user settings? Does anything change when you comment out the extensions in the devcontainer.json and rebuild the container?

[Jademalo]

Nope, those two files are the only two things I have configured. Disabling the extension installs also didn't improve anything.

However, I think I've found the culprit.

# Codespaces bash prompt theme
__bash_prompt() {
    local userpart='`export XIT=$? \
        && [ ! -z "${GITHUB_USER}" ] && echo -n "\[\033[0;32m\]@${GITHUB_USER} " || echo -n "\[\033[0;32m\]\u " \
        && [ "$XIT" -ne "0" ] && echo -n "\[\033[1;31m\]➜" || echo -n "\[\033[0m\]➜"`'
    local gitbranch='`\
        if [ "$(git config --get codespaces-theme.hide-status 2>/dev/null)" != 1 ]; then \
            export BRANCH=$(git symbolic-ref --short HEAD 2>/dev/null || git rev-parse --short HEAD 2>/dev/null); \
            if [ "${BRANCH}" != "" ]; then \
                echo -n "\[\033[0;36m\](\[\033[1;31m\]${BRANCH}" \
                && if git ls-files --error-unmatch -m --directory --no-empty-directory -o --exclude-standard ":/*" > /dev/null 2>&1; then \
                        echo -n " \[\033[1;33m\]✗"; \
                fi \
                && echo -n "\[\033[0;36m\]) "; \
            fi; \
        fi`'
    local lightblue='\[\033[1;34m\]'
    local removecolor='\[\033[0m\]'
    PS1="${userpart} ${lightblue}\w ${gitbranch}${removecolor}\$ "
    unset -f __bash_prompt
}
__bash_prompt

This is automatically added to .bashrc, and seems to run a few git commands to create a dynamic prompt. For whatever reason, it seems like this is taking a long time to execute when opening the source code folder from windows with a bind mount, making the terminal difficult to use.

This seems to come form here - https://github.com/microsoft/vscode-dev-containers/blob/e00b058f778ed105e941b0543c59cb21d71742e9/script-library/common-debian.sh#L301

[Chuxel]

You can disable the prompt using git config codespaces-theme.hide-status 1. If you have a very larger repo this can happen.

See https://github.com/microsoft/vscode-dev-containers/blob/main/script-library/docs/common.md#speeding-up-the-command-prompt-in-large-repositories

[Jademalo]

Ah! Fantastic, this at least migitates the issue.

The repo is decently sized, but not exactly huge. It seems to run absolutely fine when the code is in a volume, it's only when the code is using a bind mount to a windows folder that it hangs on the git command before showing the prompt.

I'm wondering if there are issues with linux git being run on a windows filesystem, I seem to remember there being issues with git when trying to use WSL with the code stored on the host rather than on the WSL filesystem.

[Chuxel]

Yeah NTFS is going to be noticeably slower that if you use the WSL filesystem (or a volume, which is a Linux filesystem). It's effectively going through a share. NTFS is also less efficient with lots of small files which adds to the problem.

This is a tip on reusing the git credential manager on the Windows side in WSL if you are not ware of that: https://docs.microsoft.com/en-us/windows/wsl/tutorials/wsl-git#git-credential-manager-setup

Windows and Linux also have different line ending defaults, so generally I'd recommend git cloning in WSL and using Remote - WSL extension to edit files directly if you need to rather than flipping back to Windows. VS Code will keep things with the line endings that were originally used either way, but it helps with new files.

[Jademalo]

Alright, that makes a lot of sense, thanks.

Biggest issue personally is I'm using a piece of windows software that edits map data for a game, and it entirely fails editing when the code is hosted on WSL due to a Qt bug. Seems I'm stuck between a rock and a hard place.

Ah well, at least I know what the issues are now, and how to make the terminal usable at least. Appreciate the help, ty!

[farzonl]

Is there a work around for this issue. I've tried adding:

.git
.git/
**/.git

to a .dockerignore file but remote container is not respecting the .dockerignore preferences. As a result I'm stuck with git bash when I don't need it.

[artm]

This is a tip on reusing the git credential manager on the Windows side in WSL if you are not ware of that: https://docs.microsoft.com/en-us/windows/wsl/tutorials/wsl-git#git-credential-manager-setup

this tip breaks git support inside the dev containers. It suggests to configure a windows executable as credential helper, but the executable isn't available inside the container and git refuses to start. Bind-mounting /mnt/c inside the container doesn't help either because the executable still remains unusable for some reason.

[artm]

Nevermind, git config was broken in my wsl, It was therefore copied as is to the container and remained broken.

[Chuxel]

The latest version of the images and the common utils Dev Container Feature will have the "dirty" check off by default as well.