-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Running Git Bash from the Git GUI always launches it within a Windows default console #490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
For me this change did the trick:
Not sure however on how to implement this independent of the installation directory of Git and how to bring back this change into the git-gui project... |
@tomyy This is promising! The way I did things in c930764 was to use the absolute path of the script itself and transform it into the path of the desired executable, then detect whether it actually exists (because Git GUI can be run in many more setups than Git for Windows, and # Use /git-bash.exe if available
set normalized [file normalize $::argv0]
regsub "/mingw../libexec/git-core/git-gui$" \
$normalized "/git-bash.exe" cmdLine
if {$cmdLine != $normalized && [file exists $cmdLine]} {
set cmdLine [list "Git Bash" $cmdLine &]
} else {
set cmdLine [list "Git Bash" bash --login -l &]
}
.mbar.repository add command \
-label [mc "Git Bash"] \
-command {eval exec [auto_execok start] $cmdLine} Could you test whether that works, too? |
I tested that too and it works fine with the Windows command prompt and with MinTTY. I've created a pull request: #492 |
Perfect, thanks! |
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes git-for-windows#490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes git-for-windows#490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes git-for-windows#490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes git-for-windows#490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes git-for-windows#490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes git-for-windows#490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows 2.x ships with an executable that starts the Git Bash with all the environment variables and what not properly set up. It is also adjusted according to the Terminal emulator option chosen when installing Git for Windows (while `bash.exe --login -i` would always launch with Windows' default console). So let's use that executable (usually C:\Program Files\Git\git-bash.exe) instead of `bash.exe --login -i` if its presence was detected. This fixes #490 Signed-off-by: Thomas Kläger <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
…sing virtual filesystem This replaces git-for-windows#493 (can't reopen a PR after a force-push...). I updated this commit with a more firm version of the fix. This hopefully answers Victoria's excellent concerns with the previous approach. I did not manage to get an automated test for this, but I did carefully verify this manually with a few commits in a VFS for Git enlistment (with different files every time). I updated the commit message with more details about why this works. --- This fork contains changes specific to monorepo scenarios. If you are an external contributor, then please detail your reason for submitting to this fork: * [X] This change only applies to the virtualization hook and VFS for Git. Resolves git-for-windows#490.
During installation of git 2.6.1 on the page "Configure the terminal emulator to use with Git Bash" I selected the option "Use MinTTY".
This works fine if I have a folder open in the Windows Explorer and select the option "Git Bash Here".
However, if I launch the Git GUI by using "Git GUI Here" and then start "Git Bash" from within the Git GUI, Git Bash will start with a Windows default console window.
This is a computer running Windows 8.1 (64 bit) and git version 2.6.1.windows.1 (also 64 bit)
The text was updated successfully, but these errors were encountered: