Panics on bare repositories

[etrianag]

Describe the bug
Unable to execute gitui inside a bare repo.

To Reproduce
Steps to reproduce the behavior:

1. git init --bare test-repo
2. cd test-repo
3. gitui
4. See panic message

Expected behavior
May be a message: Sorry no support for bare repos

Desktop (please complete the following information):

• OS: Kubuntu 20.04

Additional context

• Shell: Bash

[extrawurst]

Hi @etrianag thanks for your interest in gitui. This is definitely not solved elegantly, I will make that a better error message for now and not support bare repos for the time being. is there a significant use case for a tool like gitui inside bare repos to make this a feature request to support them?

[extrawurst]

should print this now:

invalid git path
please run gitui inside of a valid git (non-bare) repository

[etrianag]

Normally, I don't use bare repos, but by chance, the most recent repository I used, was a bare repo, because I was setting it to handle my dotfiles, and today a found this program, and giving my first try, it was natural to test in my last repo, so I discovered the problem. Just reported to improve gitui.
By the way, I checked in a normal repo, with a lot of commits, and I'm impressed with it: good job!.
So, I will not consider making gitui "bare repo" compatible, at least in my opinion, a feature request.
I'm not english native, but I suggest to change the message a little, because a bare repo, is a valid git repo.

An off topic question: It would be useful to add a cli option like -v, to see the version, ie: "gitui -v". Or maybe "gitui --help" to show usage. (I don't know if creating issues for simple things, like this question, is good or not for the project).

Thanks for responding so quickly, and congratulations by this project.

[extrawurst]

regarding the wording, you are right, I will rephrase it👍

the version command line arg is actually in master already (since of #88) and will roll out in the next release:

gitui --version
gitui 0.4.0

[jtrv]

Could we reopen this issue as a feature request and at least keep it in the backlog?

I store my dotfiles in a git bare repository, and many of my friends do as well. Lazygit already has this feature and it's pretty much the only thing that keeps me from switching to Gitui as my default. Using lazygit for my dotfiles was actually how I got comfortable with lazygit and began testing and learning about some of the more advanced functionality. It really improved my understanding and knowledge of lazygit and git as a whole.

Interaction with git bare repositories would give Gitui more feature parity and open it up as a way for others like me to practice and get used to the tool with their dotfiles before using it in production.

[extrawurst]

Well this ticket is part of the backlog :)
If you ever feel like it come and join me by contributing this feature, I’d for sure take it.

[mmahmoudian]

@JacobTravers Thanks for the Lazygit 👍 I played with it for few minutes and seems it matches my needs regarding bare repos. I'm not a big fan of Go, but functionality comes first.

[revred]

not support bare repos for the time being. is there a significant use case for a tool like gitui inside bare repos to make this a feature request to support them?

I am trying to use git as a no-sql local database. Support to this feature is going to be a critical decision in choosing the git client. Could I request for this feature and if a tentative timeline can be provided, please?

[basbebe]

Bare Repos are often used Tonfall dotfiles.
Tools like yadm also use this method

[extrawurst]

i am Open for contributions.

For the time being, Lazygit provides this: #100 (comment)

[jtrv]

If anybody is interested in trying to implement this, here is the relevant commit in lazygit where support for bare-repos was added. It might be worthwhile for a general idea of the sort of changes gitui may need.

[newsch]

I looked into this a couple days ago:

I commented out the two checks for bare repositories (here and here), tried it with my dotfiles repo and a bare copy of gitui, and it worked fine (no panics or program-ending errors).

For my dotfiles it picked up the correct worktree and I could add/remove/commit files just fine. It worked regardless of whether or not core.worktree was set in the local git config, which I'm a little confused by - maybe because the working directory is still the parent folder of the bare repo?

For the bare repo with no worktree, the Status/Stashing screens were stuck at "Loading ..." but the Log and Files screens worked fine.

I looked for the origin of the "bare repo" error/panic, and it looks like it's been there from the second commit in the repository. @extrawurst do you happen to remember why that check was added?

At that point it looks like the Repository::init constructor was used, which when I switched to it didn't work the same way with the bare repositories (it treated the contents of the foo.git directory as the working tree).

The libgit2 implementation of the Repository::open_ext that's used now seems much more complex in what it accepts and allows.

Providing the worktree/workdir directly through git2-rs with set_workdir seems to work, but rewriting the application to pass it around seems like it will involve a bit of refactoring since it currently uses a hardcoded "./".

I'm willing to work on the issue, but I'd like to clear up a couple of things:

• whether the git environment variables should also be respected (GIT_DIR and GIT_WORK_TREE)
• what the desired behavior of the Status/Stashing screens are for bare repositories with no working tree

[extrawurst]

Yeah I was wondering the same, I have a local change set half way converting the entire code base to accept a more complex type that lets us specify not only the git folder but also the work tree folder.
Hope to have that merged on the weekend, I am glad if you could pick it up from there

[extrawurst]

what the desired behavior of the Status/Stashing screens are for bare repositories with no working tree

probably disabling those parts and showing clear message overlays that the status area is not usable in bare repos without workspace

[extrawurst]

whether the git environment variables should also be respected (GIT_DIR and GIT_WORK_TREE)

if that’s a thing we can easily support it I think

[extrawurst]

It’s tracked here now: #1026

[extrawurst]

The eagle has landed. please give the new bare repo feature a spin (including the new workdir argument)
Would be very handy if someone actually using this pattern for dotfiles can validate! see #1026

[extrawurst]

@newsch do you want to tackle #1029 now?