Notepad++ keeps open on git pull after update to 2.44.0.windows.1

[gemal]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
  64bit

$ git --version --build-options

git version 2.44.0.windows.1
cpu: x86_64
built from commit: ad0bbfffa543db6979717be96df630d3e5741331
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Windows 11 64bit
Microsoft Windows [Version 10.0.22631.3155]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Notepad++
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

** insert your response here **

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

CMD

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git pull --verbose upstream develop

• What did you expect to occur after running these commands?

In version 2.43 no editor pops up. In 2.44 my editor pop up when there are files to get
It the same thing on 2 PCs. I reverted back to 2.43 on my home PC and it works just fine again

• What actually happened instead?

Edtior shows

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

** insert URL here **

[dscho]

I cannot see this behavior here.

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

** insert your response here **

I suspect that you have something like pull.rebase configured on your side? Or a post-receive hook or something like that?

[gemal]

Absolutly nothing special. No hooks or anything
pull.rebase=false
in the git config

[gemal]

It works fine in 2.43, but not in 2.44

[gemal]

I cannot see this behavior here.

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

** insert your response here **

I suspect that you have something like pull.rebase configured on your side? Or a post-receive hook or something like that?

can I run it in debug mode or?

[dscho]

You can run it with GIT_TRACE=1.

[mvoelker]

I have a similar nagging problem since the new version 2.44.0.windows.1.
Did not occur in previous versions.

Following a git flow pattern in a test repo with main, develop and release branches.
Steps to reproduce the problem / changed behavior:

• Given I have an empty folder and init a git repo
• Create a main branch, add a file with contents and commit that
• Create a develop branch, add another file with contents and commit that
• Create a release/version-01 branch, add another file with contents and commit that
• Switch back to main branch, add another file with contents and commit that (something like a hotfix for example)
• Switch to the release/version-01 branch and execute git merge main
• Then the shell window shows: hint: Waiting for your editor to close the file...
• Notepad++ opens .git/MERGE_MSG with the following contents

Merge branch 'main' into release/version-01
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.

That is different to previous version. Neither the hint: ... was visible not did Notepad++ open with that message.

It looks to me as if git merge --no-edit main was the default before as the first line - Merge branch 'main' into release/version-01 - was added to the log without opening an editor window in previous versions.

And I had similar problems as described in this issue when merging changes from the origin branch.

Solution would be to restore the previous behavior and make --no-edit the default again. (If a change here is the reason of course.)

[gemal]

still the same problem with 2.45