Cannot lock the ref -> detached HEAD #186
Comments
|
If you want to check the git-new-workdir.bat that I ported to work on any windows: |
|
Let's just paste the script here so that everybody involved can be certain that they have the revision that you are talking about: @echo off
goto :start
:usage
echo usage: %0 <repository> <new_workdir> [<branch>]
goto :eof
:start
set argC=0
for %%x in (%*) do Set /A argC+=1
if %argC% LSS 2 goto usage
if %argC% GTR 3 goto usage
set orig_git=%1
set new_workdir=%2
set branch=%3
rem want to make sure that what is pointed to has a .git directory ...
pushd "%orig_git%"
IF ERRORLEVEL 1 (
echo cannot change to directory: "%orig_git%"
goto eof
)
set git_dir=
for /F %%l in ('git rev-parse --git-dir') do set git_dir=%%l
IF ERRORLEVEL 1 (
echo Not a git repository: "%orig_git%"
goto eof
)
popd
if %git_dir%==.git set git_dir=%orig_git%\.git
if %git_dir%==. set git_dir=%orig_git%
rem don't link to a configured bare repository
for /F %%l in ('git --git-dir="%git_dir%" config --bool --get core.bare') do set isbare=%%l
if ztrue==z%isbare% (
echo "%git_dir%" has core.bare set to true, remove from "%git_dir%/config" to use %0
goto eof
)
rem don't link to a workdir
for %%l in ("%git_dir%\config") do set config_attribs=%%~al
if "%config_attribs:~-1%" == "l" (
echo "%orig_git%" is a working directory only, please specify a complete repository.
goto eof
)
rem don't recreate a workdir over an existing repository
if exist %new_workdir% (
echo destination directory '%new_workdir%' already exists.
goto eof
)
rem make sure the links use full paths
pushd "%git_dir%"
for /F %%l in ('cd') do set git_dir=%%l
popd
rem create the workdir
md "%new_workdir%\.git"
IF ERRORLEVEL 1 (
echo unable to create "%new_workdir%"!
goto eof
)
rem create the links to the original repo. explicitly exclude index, HEAD and
rem logs/HEAD from the list since they are purely related to the current working
rem directory, and should not be shared.
md "%new_workdir%\.git\logs"
for %%l in (config refs logs/refs objects info hooks packed-refs remotes rr-cache svn) do (
if exist "%git_dir%\%%l\" (
mklink /D "%new_workdir%\.git\%%l" "%git_dir%\%%l"
) else (
mklink "%new_workdir%\.git\%%l" "%git_dir%\%%l"
)
)
rem now setup the workdir
pushd "%new_workdir%"
rem copy the HEAD from the original repository as a default branch
copy "%git_dir%\HEAD" .git\HEAD
rem Need to remove the git_dir variable, otherwise git checkout would pick it up
set git_dir=
rem checkout the branch (either the same as HEAD from the original repository, or
rem the one that was asked for)
git checkout -f %branch%
popd
:eofIn addition, I would really like you to look into creating a Minimal, Complete & Verifiable Example, i.e. a script that demonstrates the failure (which is much more painless a way to recreate the problem in other developers' setups than any other method). |
|
Also, please note that I just marked this as a "question" rather than a bug because the problems occur due to the use of scripts and methods that are not officially supported by Git for Windows. That means that I, personally, as maintainer of Git for Windows will have to pay more attention to other tickets that are about officially supported features. It also means that I appreciate whatever improvements this ticket brings to Git for Windows. |
|
Hi dscho, I'm putting together an exact and minimal test case to follow. I'm not sure about the question, though. It used to work with 2.4.0.1, but no longer works, but I know what you mean. |
|
Rats, you can only get into the situation of a deatched head if you used a mix of 2.4.0.1 and 2.4.2.1. But the lock can be easily reproducable: Output for 2.4.0.1: For 2.4.2.1: |
|
Let me also explain my use-case, just you know why I (some the others in our company) use this feature. It really all started when we changed from hosting git internally to an external party. They have a really bad link to switzerland. Cloning our main repo takes two hours, which is just above 1GB in size. You can argue that you only need this once, but that's not quite true when you use eclipse as an IDE. Eclipse is really, really bad when it comes to switching branches and projects that were added/removed when switching. Hence we were "forced" to have for each branch a separate git working directory. To be able to still see changes in future branches without having to pull each of the branches, we opted to use the git-new-workdir, which works pretty well. The only known drawback up til now was, you could only run git-gc on the un-symlinked repo. Anyhow, that the reason why we use git-new-workdir. Would love to see it working again in 2.4.2 :) Thanks for all the hard work you're doing! |
|
I nailed it down and it's not in git-for-windows at all! After a bit of debugging, i landed in sha1_file.c/safe_create_leading_directories(".git/refs/heads/old"). The stat(".git", *) says "Yeah... path exists and in the next iteration stat(".git/refs", *) returns 0, so it tries to mkdir(".git/refs") which returns EEXIST, but then there's the check that's calling stat again, which will fail everything. So in summary: not an issue in git-for-windows. But it's an issue in the stat function. Could you tell me where I could file this? |
|
Sorry... it's actually both stat() and S_ISDIR() that are buggy with symlinks under windows. |
|
Also for the records: In the git-new-workdir.bat, I've used a directory symbolic link (mklink /D). If I use a directory junction (mklink /J) it works perfectly. Closing this issue. But would still like to file the stat() and S_ISDIR bug somewhere. |
|
Awesome job @lchiocca !
Actually we override the You can find the definition here and I think that |
|
Should I thus reopen the issue or create a new one? |
|
(Reopening, thus answering your question 😉) |
|
@lchiocca I could use your help here... |
|
No problem, just ask... i wont be able to turn on the pc this weekend (3 kids wanting to play), but on monday i can do some 'real' work ;-) . What would you like to know? |
Well, given that I already worked pretty hard to provide you with an almost working Git for Windows 2.x, I hoped I did not need to beg for something in return. But here you go: please work on resolving this ticket. |
|
Was not meant that way. When people ask for help, it can mean anything from "I've got it - could you test it" to "would you help me fix the code". Didn't know what you expected. Sure, I'll try to get it fixed! |
|
Hoi Johannes, I've debugged into the code a bit more and found a more conceptual problem. There seems to be a clash in "git-symlinks" and "filesystem-symlinks". In our repositories, we don't use git-symlinks but use filesystem symlinks. Hence git-config/core.symlinks is false. But some mingw functions are dependent on the core.symlinks config (chdir, stat, symlink, readlink), which I think is not quite right.
That would mean that the check in mingw_stat() should not check the "has_symlinks" flag at all. I've added a pull-request for it. Cheers |
|
@dscho, I've added the pull-request that was promptly rejected. I'll leave it up to you. |
…gress to verify multi-pack-index: add --no-progress to verify
When rebasing a sym-linked repository, I'm getting a detached head in 2.4.2.1, which didn't happen in 2.4.0.1. The setup is as following:
Here is the console output (first with 2.4.0.1 then with 2.4.2.1):
The text was updated successfully, but these errors were encountered: