Re: `git worktree list` when bare repository is named `.git`

[Caleb White <cdwhite3@pm.me>]

On Fri Oct 11, 2024 at 11:19 AM CDT, Rebecca Turner wrote:
> 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.

If your repository is already set up in the layout you describe, you can
just execute `git worktree add` (I have this aliased to `g w add`, I'm a
lazy typer haha) in the `my-repo` directory.

>    For a non-bare main worktree, that directory is the parent of the main
>    worktree.

I would *not* do this, you may just want to not support this case. I
imagine most folks have a common directory for all their repositories,
and polluting the parent directory with worktrees sounds like a bad idea.

>
>    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.

Note that you can use `rev-parse` to get the actual directory:

    git rev-parse --absolute-git-dir
    ~/sources/bare-repo/.git

> 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.)

To convert an existing repository to this layout, all you should have to
do is:
- Add `bare = true` to the `[core]` section of the `.git/config` file
- Remove everything except the `.git` directory
- Create a new worktree for the default branch
- Profit!

>> 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.

I've created a helper script[1] that allows me to clone a bare repository
to use with worktrees. In case you don't know, any script in your PATH
that starts with `git-` can be called as `git <script-name>`. I then
have a git alias for this script and so I can run the following to set
everything up:

    git cloneb https://github.com/git/git

The script also allows setting up an upstream remote at the same time
in case you've forked the repository.

    git cloneb --remote=https://github.com/git/git https://github.com/<user>/git

[1]: https://github.com/calebdw/dotfiles/blob/master/scripts/git-clone-bare-for-worktrees

Best,