You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
worktree: detect from secondary worktree if main worktree is bare
Setup:
1. Have a bare repo with core.bare = true in config.worktree
2. Create a new worktree
Behavior:
From the secondary worktree the main worktree appears as non-bare.
Expected:
From the secondary worktree the main worktree should appear as bare.
Why current behavior is not good?
If the main worktree is detected as not bare it doesn't allow
checking out the branch of the main worktree. There are possibly
other problems associated with that behavior.
Why is it happening?
While we're inside the secondary worktree we don't initialize the main
worktree's repository with its configuration.
How is it fixed?
Load actual configs of the main worktree. Also, skip the config loading
step if we're already inside the current worktree because in that case we
rely on is_bare_repository() to return the correct result.
Other solutions considered:
Alternatively, instead of incorrectly always using
`the_repository` as the main worktree's repository, we can detect
and load the actual repository of the main worktree and then use
that repository's `is_bare` value extracted from correct configs.
However, this approach is a bit riskier and could also affect
performance. Since we had the assignment `worktree->repo =
the_repository` for a long time already, I decided it's safe to
keep it as it is for now; it can be still fixed separately from
this change.
Real life use case:
1. Have a bare repo
2. Create a worktree from the bare repo
3. In the secondary worktree enable sparse-checkout - this enables
extensions.worktreeConfig and keeps core.bare=true setting in
config.worktree of the bare worktree
4. The secondary worktree or any other non-bare worktree created
won't be able to use branch main (not even once), but it should be
able to.
Signed-off-by: Olga Pilipenco <[email protected]>
0 commit comments