# [BUG] Git Bash no longer detaches GUI processes with & in version 2.51.0

3 messages from 2025-09-26 to 2025-09-26. Participants: Tiago Gomes, Johannes Schindelin.
Thread: https://gitlist.dev/t/64214

## Tiago Gomes, 2025-09-26 08:46

Subject: [BUG] Git Bash no longer detaches GUI processes with & in version 2.51.0
Message-ID: <GVAP278MB0582C91C40BC818FD57C59F6F91EA@GVAP278MB0582.CHEP278.PROD.OUTLOOK.COM>
URL: https://gitlist.dev/e/GVAP278MB0582C91C40BC818FD57C59F6F91EA%40GVAP278MB0582.CHEP278.PROD.OUTLOOK.COM

```
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
I installed the version Git-2.51.0-64-bit.exe.

What did you expect to happen? (Expected behavior)
I expected the same behavior as with Git-2.45.2-64-bit.exe. In that version, I could use Git Bash to run Makefile targets that launch GUI applications (like Vivado) using the command chaining or backgrounding operator (&). This allowed the GUI tool to open while the Git Bash console remained responsive. I could continue typing commands even with the GUI still running.

What happened instead? (Actual behavior)
With version 2.51.0, this behavior no longer works. When a GUI tool is launched using &, the Git Bash console becomes blocked and does not accept further input until the GUI application is closed.

What's different between what you expected and what actually happened?
Previously, using & to launch a GUI application would detach it from the shell, allowing the console to remain interactive. In Git 2.51.0, the shell remains blocked until the GUI process exits, which breaks workflows that rely on non-blocking GUI launches.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.45.2.windows.1
cpu: x86_64
built from commit: 91d03cb2e4fbf6ad961ace739b8a646868cb154d
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19045
compiler info: gnuc: 14.1
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe


[Enabled Hooks]
This email and any attachments are intended for the sole use of the named recipient(s)
and contain confidential information that may be proprietary, privileged or copyrighted under applicable law.
If you are not the intended recipient, please notify the sender immediately and destroy all copies.
This email including its attachments does not constitute a binding offer and any prices and dates stated in this email are non-binding indications.

```

## Johannes Schindelin, 2025-09-26 10:00

Subject: Re: [BUG] Git Bash no longer detaches GUI processes with & in version 2.51.0
Message-ID: <3dbf6ce2-6aed-8b47-3c8a-ab2844c1dd7f@gmx.de>
URL: https://gitlist.dev/e/3dbf6ce2-6aed-8b47-3c8a-ab2844c1dd7f%40gmx.de
In-Reply-To: <GVAP278MB0582C91C40BC818FD57C59F6F91EA@GVAP278MB0582.CHEP278.PROD.OUTLOOK.COM>

```
Hi Tiago,

On Fri, 26 Sep 2025, Tiago Gomes wrote:

> What did you do before the bug happened? (Steps to reproduce your issue)
> I installed the version Git-2.51.0-64-bit.exe.
> 
> What did you expect to happen? (Expected behavior)
> I expected the same behavior as with Git-2.45.2-64-bit.exe. In that version, I could use Git Bash to run Makefile targets that launch GUI applications (like Vivado) using the command chaining or backgrounding operator (&). This allowed the GUI tool to open while the Git Bash console remained responsive. I could continue typing commands even with the GUI still running.
> 
> What happened instead? (Actual behavior)
> With version 2.51.0, this behavior no longer works. When a GUI tool is launched using &, the Git Bash console becomes blocked and does not accept further input until the GUI application is closed.

I just tried this:

  me@work MINGW64 ~
  $ git version
  git version 2.51.0.windows.1.77.gade1f1c136.20250926063933

  me@work MINGW64 ~
  $ git gui &
  [1] 280

  me@work MINGW64 ~
  $ pwd
  /c/Users/me

I doubt that the behavior difference is due to the different version (I am
using the v2.51.0(2) preview from
https://github.com/git-for-windows/git-for-windows-automation/actions/runs/18030062242).

Could you try that preview? You can use the Portable version so that you
do not have to "clobber" your existing installation.

Ciao,
Johannes

```

## Tiago Gomes, 2025-09-26 10:36

Subject: RE: [BUG] Git Bash no longer detaches GUI processes with & in version 2.51.0
Message-ID: <GVAP278MB0582E314F3EBB51FC2DAEAB2F91EA@GVAP278MB0582.CHEP278.PROD.OUTLOOK.COM>
URL: https://gitlist.dev/e/GVAP278MB0582E314F3EBB51FC2DAEAB2F91EA%40GVAP278MB0582.CHEP278.PROD.OUTLOOK.COM
In-Reply-To: <3dbf6ce2-6aed-8b47-3c8a-ab2844c1dd7f@gmx.de>

```
Hi Johannes,

I tried it with the portable version and it works for me as well.
I went back and installed the regular version 2.51.0.windows.1 and "git gui &" also works as expected.

However, when calling my Makefile, the version 2.51.0 does behave differently than 2.45.2 for some reason. I created a minimal Makefile for you to try to reproduce it.

Create a Makefile file with this content (please make sure the last line starts with a TAB and not 4 spaces):

CMD=cmd //c
git_gui=${CMD} "git --version && git gui"

open_git_gui:
        $(git_gui) >/dev/null 2>&1 &

I am using this Make version:
$ make --version
GNU Make 3.81

When you call "make open_git_gui" you will hopefully reproduce my issue where the console is not available until you close the GIT GUI.
If you run it with git version 2.45.2 the bash becomes available immediately.

PS. My Makefile handles things a bit differently depending if the user is on Windows or Linux, so on Windows it actually calls the Command Line to execute the commands. Nevertheless, I would expect things to behave the same on git-bash no matter the git version.

Thank you.
Cheers,
Tiago




-----Original Message-----
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Sent: Friday, 26 September 2025 12:00
To: Tiago Gomes <tiago.gomes@enclustra.com>
Cc: git@vger.kernel.org
Subject: Re: [BUG] Git Bash no longer detaches GUI processes with & in version 2.51.0

[You don't often get email from johannes.schindelin@gmx.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hi Tiago,

On Fri, 26 Sep 2025, Tiago Gomes wrote:

> What did you do before the bug happened? (Steps to reproduce your
> issue) I installed the version Git-2.51.0-64-bit.exe.
>
> What did you expect to happen? (Expected behavior) I expected the same
> behavior as with Git-2.45.2-64-bit.exe. In that version, I could use Git Bash to run Makefile targets that launch GUI applications (like Vivado) using the command chaining or backgrounding operator (&). This allowed the GUI tool to open while the Git Bash console remained responsive. I could continue typing commands even with the GUI still running.
>
> What happened instead? (Actual behavior) With version 2.51.0, this
> behavior no longer works. When a GUI tool is launched using &, the Git Bash console becomes blocked and does not accept further input until the GUI application is closed.

I just tried this:

  me@work MINGW64 ~
  $ git version
  git version 2.51.0.windows.1.77.gade1f1c136.20250926063933

  me@work MINGW64 ~
  $ git gui &
  [1] 280

  me@work MINGW64 ~
  $ pwd
  /c/Users/me

I doubt that the behavior difference is due to the different version (I am using the v2.51.0(2) preview from https://github.com/git-for-windows/git-for-windows-automation/actions/runs/18030062242).

Could you try that preview? You can use the Portable version so that you do not have to "clobber" your existing installation.

Ciao,
Johannes
This email and any attachments are intended for the sole use of the named recipient(s)
and contain confidential information that may be proprietary, privileged or copyrighted under applicable law.
If you are not the intended recipient, please notify the sender immediately and destroy all copies.
This email including its attachments does not constitute a binding offer and any prices and dates stated in this email are non-binding indications.

```
