On Thu Oct 10, 2024 at 11:59 PM CDT, Rebecca Turner wrote:
> Perhaps your example got scrambled, but I can't quite reproduce it:
>
> $ mkdir -p repo/.bare
> $ cd repo/.bare
> $ git init --bare
> Initialized empty Git repository in /private/tmp/repo/.bare/
> $ git worktree list
> /private/tmp/repo/.bare (bare)
> $ cd ..
> $ git worktree list
> fatal: not a git repository (or any of the parent directories): .git
> $ echo 'gitdir: .bare' >.git
> $ git worktree list
> /private/tmp/repo/.bare (bare)
> It seems like the $GIT_DIR is shown in the worktree list here, and when I add
> a `.git` file pointing to `.bare` manually, that doesn't get listed. (Which I
> suppose makes sense, because it's not a `git-worktree(1)` worktree, but still
> seems a little bit odd?)
Ah, I was mistaken. It will show the actual path if the gitdir points
to a separate directory.
> I understood this note to be talking about paths _within_ the `$GIT_DIR` or
> `$GIT_COMMON_DIR` itself; I see no reason why `git worktree list` wouldn't list
> a bare repository _consistently_ as either the `$GIT_DIR` or the parent of the
> `$GIT_DIR`.
>
> What I'd like to do is get the path of the worktree so that I can move it. `git
> worktree list` gives me this information _except_ for bare repositories in
> directories named `.git`. I'm happy to have a special case for this, but I'd
> like to understand the principle here.
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?
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 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).
> Maybe I'm just not supposed to name a bare repository `.git`? The
> `gitrepository-layout(5)` page does seem to imply this is mutually exclusive
> with bare repositories:
>
>> A Git repository comes in two different flavours:
>>
>> • a .git directory at the root of the working tree;
>>
>> • a <project>.git directory that is a bare repository (i.e. without its
>> own working tree), that is typically used for exchanging histories with
>> others by pushing into it and fetching from it.
There's nothing wrong with naming a bare repository `.git`. I've been
doing it for a while now and it works just fine.
I've become a big fan of using bare repositories with worktrees,
particularly in high-trafficked repositories where I'm constantly
switching between branches.
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.
Best,
