Hi Jörg, would you be able to follow the same advice I have at https://github.com/git-for-windows/git/issues/5427#issuecomment-2735535941 to build Git and investigate a bit further (because I cannot reproduce your problem and therefore cannot do that for you): 1. install the Git for Windows SDK: https://gitforwindows.org/#download-sdk 2. Create `/usr/src/git/config.mak` with the following contents to disable compiler optimization and ASLR: ``` DEVELOPER=1 ifndef NDEBUG CFLAGS := $(filter-out -O2,$(CFLAGS)) ASLR_OPTION := -Wl,--dynamicbase BASIC_LDFLAGS := $(filter-out $(ASLR_OPTION),$(BASIC_LDFLAGS)) endif ``` 1. run `make` in `/usr/src/git/`. After that, you can run Git's executables in GDB like so: ``` gdb --args ./git.exe -C /path/to/refs/drive init test-git-repo ``` Now, it is useful to ask the debugger to pause the program when the code path is entered that outputs an error message. The functions in Git that output error messages are `error_builtin()` and `die_builtin()`. So you can set the breakpoints ``` b error_builtin b die_builtin ``` before calling `run` in `gdb` to stop execution at the appropriate time. Doing this will stop execution when the `error_builtin()` function is called, i.e. when the error message you reported would be shown. Once that is the case, you can obtain a back trace with `bt`. Example: ``` (gdb) bt #0 setup_git_directory_gently_1 (nongit_ok=0x0) at setup.c:846 #1 0x000000000057dfd8 in setup_git_directory_gently (nongit_ok=0x0) at setup.c:937 #2 0x000000000057e211 in setup_git_directory () at setup.c:1014 #3 0x0000000000487bfc in cmd_rev_parse (argc=2, argv=0x1951a88, prefix=0x0) at builtin/rev-parse.c:589 #4 0x000000000040296a in run_builtin (p=0x5fb8e8 <commands+2184>, argc=2, argv=0x1951a88) at git.c:373 #5 0x0000000000402c8d in handle_builtin (argc=2, argv=0x1951a88) at git.c:579 #6 0x0000000000402e2a in run_argv (argcp=0x108fe00, argv=0x108fdb8) at git.c:637 #7 0x0000000000402fb9 in cmd_main (argc=2, argv=0x1951a88) at git.c:709 #8 0x000000000049f699 in mingw_main (argc=3, argv=0x1951a80) at common-main.c:40 #9 0x000000000049f64d in main (argc=3, argv=0x3230498) at common-main.c:25 ``` This back trace shows which functions were called by which other functions. The inner-most code location is `#0`, which was called from `#1`, which was called from `#2`, etc. In the example above, the `main()` function called the `mingw_main()` function which in turn called the `cmd_main()` function, and so on, until eventually the `setup_git_directory_gently()` function was called, which then called the `setup_git_directory_gently_1()` function, where the execution was stopped to let you, the user, inspect the current state in the debugger. You can inspect the source code at the current code location using the `l` command (or specify a line number or even a file and a line number like so: `l git.c:709`, or a function name, like so: `l run_builtin`). You can navigate between the different stack frames using `up` and `down` (which is confusingly the opposite direction as in the list above). Importantly in this instance, you can go `up` to the function that issues the error message, then inspect the surrounding code with `l`. This should already be very helpful in the investigation to figure _what_ is going wrong, and if all you do to help this ticket is run with the debugging so far and then paste the output of `gdb` in this ticket, it should go a long way to fix this bug. Please let us know how it goes! On Thu, 24 Apr 2025, Hohwiller, Jörg wrote: > Hi Johannes, > > Also I see this error every time I run "git pull origin main": > > fatal: failed to run reflog > error: task 'gc' failed > > The pull still works but I guess something is really wrong but cannot tell exactly what. > > Kind regards > Jörg > > -----Original Message----- > From: Johannes Schindelin <Johannes.Schindelin@xxxxxx> > Sent: Thursday, April 24, 2025 15:10 > To: Hohwiller, Jörg <joerg.hohwiller@xxxxxxxxxxxxx> > Cc: git@xxxxxxxxxxxxxxx > Subject: RE: [Windows] Severe problems after upgrading to 2.48.1.windows.1 > > ******This mail has been sent from an external source. Do not reply to it, or open any links/attachments unless you are sure of the sender's identity.****** > > Hi Jörg, > > On Fri, 4 Apr 2025, Hohwiller, Jörg wrote: > > > Thanks for your response and suggestions. > > I downloaded and installed the latest SNAPSHOT: > > > > $ git -v > > git version 2.49.0.windows.1.7.g4ca71ba531.20250326122305 > > > > However, the error still remains. I cannot pull my repo without the error I was referring to. > > I should have clarified that you will need to remove the `.lock` file manually, unfortunately, before trying again (if it exists, that is). > > Ciao, > Johannes > > > This blocks my workflows. > > There are workarounds like using `git pull origin main` manually in git-bash but it is quite inconvenient not being able to use git via IntelliJ or git-fork without errors. > > > > Kind regards > > Jörg > > > > -----Original Message----- > > From: Johannes Schindelin <Johannes.Schindelin@xxxxxx> > > Sent: Tuesday, April 1, 2025 17:45 > > To: Hohwiller, Jörg <joerg.hohwiller@xxxxxxxxxxxxx> > > Cc: git@xxxxxxxxxxxxxxx > > Subject: Re: [Windows] Severe problems after upgrading to > > 2.48.1.windows.1 > > > > ******This mail has been sent from an external source. Do not reply to > > it, or open any links/attachments unless you are sure of the sender's > > identity.****** > > > > Hi Jörg, > > > > On Mon, 3 Mar 2025, Hohwiller, Jörg wrote: > > > > > I just upgraded to 2.48.1.windows.1 (reinstall via Git-2.48.1-64-bit.exe). > > > Also I kept the checkbox to cache files (new feature?) – maybe a mistake, let see. > > > > If you are referring to FSCache, no that's not a new feature. > > > > > After the upgrade, I pulled some repo with git-fork and got this error: > > > error: could not delete references: cannot lock ref 'refs/remotes/origin/bugfix/XY-74488': Unable to create 'D:/projects/projectname/workspaces/main/projectname/.git/refs/remotes/origin/bugfix/XY-74488.lock': File exists. > > > > While this looks different than > > https://github.com/git-for-windows/git/pull/5515 (where writing to a ReFS drive on Windows 2022 was broken by a regression), the root cause as well as its fix could be the same. Can you test the latest snapshot at https://gitforwindows.org/git-snapshots/ to confirm or refute this hypothesis? > > > > Ciao, > > Johannes > > > > > > > > I looked locally (even in CMD with copy & paste of the exact file reference) but the lock file is NOT there. > > > I repeat the pull and get the same error, but no such lock file exists. > > > > > > To avoid external side-effects from git-fork, I opened a new git-bash and called “git pull” manually in the terminal. > > > This did not give me any error but gave me this: > > > $ git pull > > > From ssh://git.company.com/repos/projectname > > > 72477d57f026..de79f4dbbf68 … > > > * [new branch] … > > > * [new branch] … > > > * [new branch] … > > > * [new branch] … > > > * [new branch] … > > > * [new branch] … > > > * [new branch] … > > > ce3979d639d7..b80b70a56da7 … > > > $ echo $? > > > 1 > > > > > > So what could be the error leading to exit code 1? > > > > > > Almost the same happens for git-fetch. > > > > > > I downgraded to git version 2.47.1.windows.2 and after that tried the same again. > > > A difference is that now I additionally I get logs like this at the > > > top $ git pull > > > remote: Enumerating objects: 269, done. > > > remote: Counting objects: 100% (143/143), done. > > > remote: Compressing objects: 100% (41/41), done. > > > remote: Total 269 (delta 89), reused 87 (delta 87), pack-reused 126 > > > Receiving objects: 100% (269/269), 59.37 KiB | 2.58 MiB/s, done. > > > Resolving deltas: 100% (94/94), completed with 51 local objects. > > > From ssh://git.company.com/repos/projectname > > > … > > > $ echo $? > > > 1 > > > > > > Looks familiar. Is it a bug or a feature that the latest git stops logging these status information? > > > > > > I have various other git repos that continue to work fine so I now rather think that this is not a general bug in git pull/fetch but related to the specific repo. > > > However, that used to work for years before I upgraded today. > > > > > > Status on that repo says: > > > $ git status > > > On branch main > > > Your branch is behind 'origin/main' by 387 commits, and can be fast-forwarded. > > > (use "git pull" to update your local branch) > > > > > > Untracked files: > > > (use "git add <file>..." to include in what will be committed) > > > find-tests.sh > > > > > > nothing added to commit but untracked files present (use "git add" > > > to > > > track) > > > > > > Sorry to bother but do you have any further hints or ideas, what I could try to fix my problem? > > > > > > Kind regards > > > Jörg > > > > > > > > > ________________________________ > > > > > > Firma: Capgemini Deutschland GmbH > > > Aufsichtsratsvorsitzender: Dr. Volkmar Varnhagen > > > Geschäftsführer: Henrik Ljungström (Sprecher) • Jost Förster • > > > Felizitas Graeber • Vera Schierholt > > > > > > Sitz: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 98814 This > > > message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. > > > > > This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. > > >
