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,
