Don't work well with bare repo and dotfiles

[Deshdeepak1]

Describe the bug I use git bare repo to manage my dotfiles . So i used, laygit -g ~/.dotfiles -w ~/ , but pressing 'a' to stage all, but lazygit got hang . I also used in vim using Floaterm. There it says file not found

To Reproduce Steps to reproduce the behavior:

1. Create a bare repo
2. Add some dotfiles (e.g. .config/nvim/init.vim ) files using 'git'
3. Commit changes
4. Edit some file
5. Try staging with lazygit this time with 'a'

Expected behavior Should work fine like other repos.

Screenshots

Desktop (please complete the following information):

• OS: arch linux
• Lazygit Version 0.26.1
• The last commit id if you built project from sources (run : git-rev parse HEAD)

Additional context Add any other context about the problem here.

[Chaitanyabsprip]

@jesseduffield I am facing the same issue

[freezboltz]

Sudden crash in my machine after cd into my bare repo and launched lazygit.

[kotochor]

My problem is a bit different.

When I run the following alias it starts to consume a lot of resources.

alias lazydots="lazygit --git-dir='${XDG_DATA_HOME}/dotfiles-repo' --work-tree='${HOME}'"

I think it starts analyze all new files, and due to a big number of them, it's never ending

For me LazyGit is working just fine with a small Git bare repository, but not for the $HOME directory.

git-status has option --untracked-files='no', it would be nice to have similar one.

[freezboltz]

[kotochor]

@freezboltz, If I understand your screenshot correctly, than the problem here is that LazyGit not handles this "exception" properly, the error should be here.

I have the same error if I try to cd into a Git bare repository. No one should cd into a bare repo. To use Git or LazyGit with a bare repository, two properties expected: --git-dir='<bare_repo_loc>', --work-tree='<files_loc>' I have the example above

[danielyrovas]

also facing this issue.

[elder-n00b]

As of today, I cannot reproduce. Perhaps it got fixed meanwhile?

Actually I was surprised to see that lazygit shows my commit history even without --git-dir/--work-tree nor GIT_DIR/GIT_WORK_TREE environment variables, I have tried to unset DOTBARE_DIR/DOTBARE_TREE and it still does, while git log in ~ errors out

fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

so I guess this case is now handled by lazygit somehow? I see a func (self *StatusCommands) IsBareRepo() bool in the sources but did not follow the rabbit yet.

I have not actually tried to operate it in this state, besides noticing I can stage/unstage all with a without problems, but I did setup $GIT_DIR/info/exclude to ignore unrelated and huge folders (cough vscode caches under .config cough) when I first initialized the repo, I think that is the reason I'm not seeing any delay. This is normal and expected though.

[maxigaz]

Lazygit still hangs for me when I repeat the steps described by OP.

[elder-n00b]

I'm confident that having set up info/exclude is the reason I did not get the hang then. My first guess is that it doesn't have to do with bare repos but the size of the working folder -- I'll test the assumption later.

[Tolomeo]

I was facing a similar issue, and solved by adding to .gitignore folders and files I won't need to be tracked in my dotfiles repo. I am working on a Mac machine, so I ended up with something like:

.DS_Store
Applications/
Desktop/
Documents/
Downloads/
Library/
Movies/
Music/
Pictures/
Projects/
Public/

plus the folder containing the bare repository itself and a few others.

[jwhitley]

The reported problems in this issue span a few different root causes. Many of these are addressed by #3183, which should land soon. However, the original report cites a use case that is a not a problem with lazygit, but with the dotfile git repo itself. In practice, you must to use a .gitignore file for a versioned homedir scenario when the homedir has a large number of files. Otherwise, there’s no way for git to know what parts of your homedir are intended to be versioned or not, and will just scan everything on some commands. For many of us, our homedirs are terabytes of junk! 😅 Likewise, there’s no equivalent to the —untracked-files=no argument to git status, since the a command is essentially git add —all.

There are two approaches to solving this problem, which work well for scanning cases like git status and git add —all:

1. Like @Tolomeo shows above, simply exclude all directories you don’t intend to version. Especially important: exclude directories that contain other git repositories, third-party repos, etc! Especially ones with node_modules dirs and the like. Your ~/src directory or similar can easily have a gigantic file count which you mostly don’t even see.
2. Homedir versioning tools like vcsh will setup a .gitignore that does two things: First, it excludes everything using * on the first line. Second, it lists every versioned file in the repo using the !/path/to/file syntax to unexclude versioned things again.

Here’s a full example from my Neovim config. This works really well, but you’ll probably want a tool like vcsh for this approach since it’s a pain to manage manually:

*
!/.config
!/.config/nvim
!/.config/nvim/.gitignore
!/.config/nvim/.neoconf.json
!/.config/nvim/LICENSE
!/.config/nvim/README.md
!/.config/nvim/init.lua
!/.config/nvim/lazy-lock.json
!/.config/nvim/lazyvim.json
!/.config/nvim/lua
!/.config/nvim/lua/config
!/.config/nvim/lua/config/autocmds.lua
!/.config/nvim/lua/config/keymaps.lua
!/.config/nvim/lua/config/lazy.lua
!/.config/nvim/lua/config/options.lua
!/.config/nvim/lua/mux.lua
!/.config/nvim/lua/plugins
!/.config/nvim/lua/plugins/cmp.lua
!/.config/nvim/lua/plugins/coding.lua
!/.config/nvim/lua/plugins/colorscheme.lua
!/.config/nvim/lua/plugins/editor.lua
!/.config/nvim/lua/plugins/example.lua
!/.config/nvim/lua/plugins/lsp.lua
!/.config/nvim/lua/plugins/tmux.lua
!/.config/nvim/stylua.toml
!/.gitignore
!/.gitignore.d
!/.gitignore.d/nvim