-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve git root detection logic #195
base: main
Are you sure you want to change the base?
Conversation
Also, as a side effect of the new implementation, the issue described in #192 seems to be solved! 🎉 Tmux + gum example using the new |
Gotta fix tests, I'll DM you and we can do some pair programming to fix it. |
… some of this anyway.)
…ks for more consistent `git worktree list` logic.
When I choose a git worktree I got this result:
But expected this::
|
Furthermore, when I call
However, I need this to be the root so I can properly leverage the root search feature:
|
I moved this to a draft for now, let me know if you want someone else to take over or have some time soon to revisit this work and finish it up, thanks! |
Firstly, a quick thank you, for all your awesome work on sesh! It's a game changer for me ❤️
The problem:
The sesh README says that
sesh root
assumes existence of a.bare
folder...Not everyone uses git worktrees this way. For example, many prefer the conventional
git clone --bare [repo] project
, which leaves you with a messy project folder, but this is still very common nonetheless.I on the other hand, prefer to run
git clone --bare [repo] project/.git
, which stores all of the git meta in.git
folder, but still creates a bare repo. This leaves me with a really clean project folder when using worktrees...The
.bare
convention is cool too, but again would require different pathing logic for each situation.A possible solution:
My proposition is to use the output of
git worktree list
, since git knows where the main worktree / bare repo lives...^ As you can see, the main worktree is always listed first, no matter how you roll with git worktrees (whether that be using
.git
, or.bare
, or doing it the messier default way.For example, this is what you see when running
git worktree list
...This PR uses
git worktree list
to grab that first field, for the basis ofsesh root
and also for thenamer
package used when naming sessions.I was able to remove all
--git-common-dir
,--show-toplevel
, and.bare
checks, because those all seem to be handled well with the first field returned bygit worktree list
; It seems to be super consistent across all situations 🎉Todo:
git worktree list
to find root from within git worktree repos.bare
convention.git
conventiongit worktree list
to find root from non-worktree repo subdirssesh root
commandnamer
package