On December 11, 2017 12:02 PM, Marc-André Lureau wrote:
>For better, or worse, I encountered a script doing a git clone --shared from
>the working directory. However, if clone --shared is run from a worktree, it
>fails with cryptic errors.
>elmarco@boraha:/tmp/test/wt (wt)$ git worktree list
>/tmp/test 4ae16a0 [master]
>/tmp/test/wt 4ae16a0 [wt]
>elmarco@boraha:/tmp/test/wt (wt)$ git clone --shared . clone-dir Cloning into
>'clone-dir'...
>done.
>error: object directory /tmp/test/.git/worktrees/wt/objects does not exist;
>check .git/objects/info/alternates.
>fatal: update_ref failed for ref 'HEAD': cannot update ref
>'refs/heads/wt': trying to write ref 'refs/heads/wt' with nonexistent object
>4ae16a066ee088d40dbefeaaae7b5578d68b4b51
>fatal: The remote end hung up unexpectedly
>Is this a bug? If not, a nicer error message would be welcome, as well as man
>page note.
"The add worktree documentation states:
Create <path> and checkout <branch> into it. The new working directory is
linked to the ***current repository***, sharing everything except working
directory specific files such as HEAD, index, etc. - may also be specified as
<branch>; it is synonymous with @{-1}."
So I'm going to assume that clone from a worktree is not supported. This sounds
like a check is needed to prevent the operation from starting up in the first
place, or changing the semantics to allow it. The error message, while cryptic,
seems actually descriptive because the HEAD would not be available in a
worktree as it is not propagated from the current repository.
If the idea is to support an add worktree from a worktree, I would suggest that
a new branch go back to the main repository as normal, rather than being added
to the worktree. I personally get a headache thinking about the prospect of
having layers of worktrees.
Cheers,
Randall
-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.
