Support for repos with separate --git-dir / --work-tree (the "bare repo dotfiles" pattern)

[LeBinhAn]

Hi! First off, thanks for all the work on this tool — I use it daily and it's made my git workflow a lot smoother.

I wanted to flag a use case that currently isn't detected as a repo, in case it's something you'd consider supporting.

The setup

A pretty popular way to manage dotfiles is to keep the actual git data in one folder, but treat your home directory as the working tree, like this:

git clone --bare <repo-url> "$HOME/.dotfiles"
alias dotfiles='/usr/bin/git --git-dir="$HOME/.dotfiles" --work-tree="$HOME"'

So $HOME/.dotfiles holds all the git metadata, and $HOME itself is the working tree — there's no .git folder inside $HOME at all. The two are linked only through --git-dir / --work-tree (or core.worktree in the bare repo's config).

Why it's not picked up

I think the client looks for a .git folder/file when scanning for repos, which makes total sense for the common case, but it means this pattern gets missed since there's nothing in $HOME to find, and $HOME/.dotfiles on its own just looks like a bare repo.

What would help

• A way to manually add a repo by specifying the git-dir and work-tree as separate paths, rather than requiring one folder with .git inside.
• If a bare repo has core.worktree set in its config, using that as the working tree instead of treating it as bare.

No worries if this is too niche to prioritize — just thought I'd share it in case it's a quick win or useful for others doing the same dotfiles trick. Happy to test anything or provide more details if helpful. Thanks again!

[LeBinhAn]

I'm sorry for forgetting to add the Feature Request prefix to the title.

[DanPristupov]

I think the client looks for a .git folder/file when scanning for repos

Yes. .git is mandatory. Why don't you add it?

gitdir: $HOME/.dotfiles

The main question is: does a simple git status without additional arguments work in such a working directory? If so, Fork should support it. If not, Fork shouldn't either.

[LeBinhAn]

Thanks for looking into it! To answer directly: no, plain git status won't work without extra arguments here. $HOME/.dotfiles is a bare repo, so even cd-ing into it and running git status just reports "bare repo, no working tree" rather than showing changes — I have to use dotfiles status, dotfiles add, etc. via the alias.

My structure looks like this:

~/                    # my home / working tree
├── .dotfiles/        # bare repo — git config + metadata only, tracks nothing on its own
├── .zshrc
├── .vimrc
└── ...                # other config files, tracked via the alias

The reason there's no .git to add: making $HOME itself a git-dir would turn my entire home directory into one giant repo. Instead, .dotfiles holds the git data separately, and --git-dir / --work-tree are what tie it to $HOME as the working tree — that pairing only exists because it's passed explicitly each time, not because of any folder convention Git can discover on its own.

This is a well-known pattern among people managing dotfiles this way, and I've been able to make it work in other tools — e.g. lazygit, by pointing it at the same paths:

lazygit --git-dir="$HOME/.dotfiles" --work-tree="$HOME" "$@"

I still prefer Fork's UI though, which is why I'm hoping this is something you'd consider. Understood if git status working out-of-the-box is the bar for support — but since the pairing just needs to be entered once when adding the repo (not auto-detected), it might be a small addition that opens Fork up to this fairly common workflow.