Running Git Bash from the Git GUI always launches it within a Windows default console #490
Labels
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! |
dscho
pushed a commit
to dscho/git
that referenced
this issue
Nov 7, 2015
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Dec 11, 2015
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Jan 5, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jan 12, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jan 14, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jan 15, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jan 23, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jan 26, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Jan 28, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Feb 6, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Feb 23, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Mar 15, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Mar 18, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Mar 29, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Apr 4, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Apr 30, 2016
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Nov 16, 2019
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Nov 25, 2019
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Nov 26, 2019
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 <thomas.klaeger@10a.ch> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
to dscho/git
that referenced
this issue
May 9, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
May 13, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jul 26, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Aug 18, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Sep 16, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Sep 22, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Sep 27, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Oct 3, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Oct 19, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Nov 23, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Nov 23, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Nov 30, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Nov 30, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Dec 6, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Dec 12, 2022
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jan 23, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Mar 17, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
May 20, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jul 11, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Aug 8, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Aug 9, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Aug 9, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Aug 11, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Aug 16, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Aug 21, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Aug 23, 2023
…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.
dscho
pushed a commit
to dscho/git
that referenced
this issue
Apr 15, 2024
…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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: