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.