Version: 2.5.0
Steps to reproduce:
gitbash in a repositorycd into some subfoldergitbashExpected:
Step 4 should be successful already.
Do you have TortoiseGit installed or any other visual Git tool that attaches to explorer and/or adds context options in the "right-click" menu ?
Yes, TortoiseGit is installed, but not used for the case above.
Use procexp.exe when you get the File or Folder still in use, then Find > Find handle or DLL... then type folder currently locked, check what process holds the directory in question and report back.
For whatever reason I can't reproduce this today anymore... weird, I could do so yesterday.
Closing this for now. If I run into it again, I'll come back with more details.
Thanks for you time guys, appreciate it!
I have this same issue.
The difference is that I used the right-click menu and this does not have to be in a git repo. I created a tmp folder on my desktop just now and still got the issue.
Used procexp.exe as @maoueh suggested and it is indeed git bash that locks it.

I had the same issue a few days ago again. Thanks for bringing this up again.
I think this is by design. git-bash.exe spawns a MinTTY which in turn spawns a bash.exe, and only that bash.exe's working directory can be changed. The other two processes need to wait for bash.exe (and then mintty.exe) to be done.
So if you gentle people have any idea how this wish can be fulfilled, let's hear it. Otherwise we'll have to close this as "Can't fix".
I think this is by design.
In this context I would rephrase that to "this is by mis-design" then to be honest. But I fully understand in this regard that this is not fixable for you.
In this context I would rephrase that to "this is by mis-design" then to be honest.
Sure, let's just talk down the work of others, without adding any effort. Is that how you want this discussion to end?
Alternatively, you could either come up with a better design and implement it, or show some grace.
Sure, let's just talk down the work of others, without adding any effort. Is that how you want this discussion to end?
Oh dear, that indeed came out totally wrong! I didn't except that anyone would interpret my writing that way. Sorry for that.
I'm for sure not somebody who does not value work of others. (Well I'm quite involved in open source stuff, so I know the pain.) It was just that your sentence was about justifying an "end-user" inconvenience with a technical reason.
In this very case I'm pretty sure that this has nothing to do with how it was designed, it's rather a side-effect of how it is (or it rather has to be) designed currently.
I fully understand that and I'm neither angry or sad or upset or anything in this regard. It' an inconvenience, not nice, but not crucial.
Just to repeat it here. I do not and did not blame anybody, I simply negated your sentence.
I do not know who exactly built what and I'm very thankful for having a working git on windows.
(I also value your personal support @dscho a lot, which I needed some months ago, and your help was very appreciated.)
Regarding the problem: No, I don't have a better idea how we could capture a cd command and inherit the cwd up to the top-level process.
Acceptable resolution for me: Closing this due to being unfixable without major effort of rewriting the whole stuff. :-)
how we could capture a
cdcommand and inherit thecwdup to the top-level process.
Would that not break the MinTTY promise that Alt+F2 clones the current window with the same working directory that the original was started from?
I have to admit that I don't know MinTTY and the inner workings. I didn't even know that shortcut, nor did I ever have the usecase you described for that shortcut.
I didn't even know that shortcut
One of the perks of taking care of this here bug tracker is that I am made aware of many features I had not even suspected to exist, including the Alt+F2 feature.
Most helpful comment
One of the perks of taking care of this here bug tracker is that I am made aware of many features I had not even suspected to exist, including the Alt+F2 feature.