> Why would you move the `.git` directory? If you're trying to move the
> repository, then wouldn't you just move the directory that contains the
> `.git` directory?
Ah, I should give some context here. I'm using worktrees with the layout you
describe later in your email:
my-repo/
.git/ <- bare git directory
main/ <- worktree for main branch
feature1/ <- worktree for feature work
...
I'm writing a tool to manage these layouts for you. I want to provide two
features:
1. The ability to add a new worktree in a slightly more magical manner; in
particular, I want to be able to do `git my-tool add feature2` and add a new
worktree in the same directory as all the other worktrees.
For a non-bare main worktree, that directory is the parent of the main
worktree.
For a bare main worktree named `.git`, it's the path of the main
worktree. (Nothing in the `git worktree list` output indicates this is the
case!)
For other bare worktrees, it's the parent of the main worktree.
2. The ability to convert an existing repository in this layout.
This requires separating the `$GIT_DIR` from the worktree and then
reassociating them, in order to convert the non-bare main worktree into a
bare main worktree and a second linked worktree. (In particular, I'd like to
avoid the cost of copying all the files in a large checkout.)
> I think the main reason why the `.git` path is trimmed is because it
> doesn't make sense to show it in non-bare repositories. No one wants to
> see the `.git` path in a normal repository.
>
> # global git
> git worktree list
> ~/sources/git 3f20f8dd05 [wt_relative_paths]
>
> # locally modified git
> ./git worktree list
> ~/sources/git/.git 3f20f8dd05 [wt_relative_paths]
I definitely agree with this!
> I would rather not have the `.git` show even in bare repositories,
> if a user has moved the bare repository to `.git`, then that would
> indicate that the *intent* is for the parent directory to essentially
> act as the repository (and be moved as a cohesive unit if moving).
I suppose that makes sense? Perhaps this is an area where the documentation
needs some additional notes.
> When I was first doing research on this, I found a ton of articles with
> all kinds of different ways to do it. Some folks put their worktrees in
> the same directory as the actual repository (intermixed with their
> code), some polluted the parent directory, some created a detached
> commit that removed all files from the default working tree and then
> created the worktrees, some used a bare repository but then just created
> the worktrees in the same directory, etc. I finally came across an
> article that showed the `.bare` method above and I thought that was the
> cleanest method. However, after using it for a while, I realized that
> I could just move `.bare` to `.git` and it would work just fine (and
> I could remove an extra file). I've been using that method ever since.
Yes, exactly! My frustration with this technique is how difficult it is to use.
I have existing checkouts I'd like to convert to worktree repositories, and
`git clone --bare` doesn't create remote-tracking branches, so it's strangely
difficult to set up repositories like this. I'm hoping to ease some of this
with my new tool.
Thanks again for your help,
-- Rebecca
