I'm trying to run git bug from a bare repository and get:

Error: git-bug must be run from within a git repo.

Related to #103?

Other operations like git log or programs like tig work happily.

$ git clone --bare https://github.com/MichaelMure/git-bug
Cloning into bare repository 'git-bug.git'...
remote: Enumerating objects: 101, done.
remote: Counting objects: 100% (101/101), done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 9417 (delta 15), reused 55 (delta 10), pack-reused 9316
Receiving objects: 100% (9417/9417), 13.94 MiB | 4.09 MiB/s, done.
Resolving deltas: 100% (5216/5216), done.
$ cd git-bug.git/
$ ls
branches  config  description  HEAD  hooks  info  objects  packed-refs  refs
$ git log --oneline | head -n 2
eef7333 commands: fix a missing line break
7988c67 Update README.md
$ git bug ls
Error: git-bug must be run from within a git repo.

Usage:

Nothing to do with #103

What's happening is rather simple. git-bug need to store on disk a few temporary files (pre-compiled bugs and identities, clocks ...). You can safely delete those and git-bug will recompute them next launch, but it does need a place to store them.

Currently, git-bug store those file in .git/git-bug/. The .git folder is found using the git rev-parse --show-top-level command, which notably doesn't work for a bare repository or if you are already inside the .git folder.

So nothing really preventing from fixing this problem, we just need to come up to the good solution.

Michael Muré (MichaelMure) changed the title from git-bug doesn't work in bare repository to git-bug doesn'y work in bare repository 6 years ago

Michael Muré (MichaelMure) added label kind/bug 6 years ago

So nothing really preventing from fixing this problem, we just need to come up to the good solution.

Use git rev-parse --git-path git-bug instead?

hooo, that's a good one ! It even work from inside .git .

Michael Muré (MichaelMure) changed the title from git-bug doesn'y work in bare repository to git-bug doesn't work in bare repository 6 years ago

Just made a quick&dirty fix for this since I'm also stuck with pushing from bare repo to bare repo. Made it on my own local clone where I'm currently working on other subjects and not ready to setup a proper pull request for this single line change that may be request less effort to simply copy and past directly in your own workspace for integration if acceptable as is. issue-178.patch.txt

@seeduvax those commands are not equivalent for a normal repo: --show-toplevel will return the root of the repository (/path/to/your/repo), --git-path . will return the .git folder (/path/to/your/repo/.git).

Consequently, git-bug will start to write files in /path/to/your/repo/.git/.git/....

@MichaelMure use git rev-parse --git-dir

Indeed it works in bare repo and no more in normal repo, I'll work deeper on it. And I observed strange behavior when using it on Debian 8 compared to Debian 9. I need further testing...

Looks much better with rafasc's command. issue-178.patch.txt Working at home with my Debian 9 (very few testing for now), I'll try tomorrow at work with other iinux distros.

I still have to take into account Michael's warning to not write in <reporoot>/.git/.git/..., but run enough to confirm git rev-parse --git-dir is the right way to retrieve the path with the two kinds of repository.

A solution might be to use the path that --git-dir return for GitRepo.Path and adjust all the usage of that variable to point to the correct place.

That way, GitRepo.Path would always point to where git store its data (which is what we really care about) instead of the checked out files for a normal repo and git's data for a bare repo.

Yes, just have to balence between the effort needed to avoid any API break (change should remain private in repository/git.go or at least repository namespace) and no abuse of cheating contatenation of .. or things like that to go back to the right place.

It's perfectly fine to change things outside of the repository package, as long as users can still load their repo. But I don't think that will be a problem with this change.

@MichaelMure I just updated my clone to restart my coding from up to date state but before doing any change, I have troubles with the build:

$ make
go generate
# github.com/MichaelMure/git-bug/vendor/github.com/99designs/gqlgen/handler
vendor/github.com/99designs/gqlgen/handler/graphql.go:709: header.Size undefined (type *multipart.FileHeader has no field or method Size)
vendor/github.com/99designs/gqlgen/handler/graphql.go:725: header.Size undefined (type *multipart.FileHeader has no field or method Size)
vendor/github.com/99designs/gqlgen/handler/graphql.go:758: header.Size undefined (type *multipart.FileHeader has no field or method Size)
git-bug.go:1: running "go": exit status 2

I checked for difference with git diff master upstream/master and can't see any. Did I missed something particular to be still able to build? Checkout to my last change let me build again OK. After checking out back to master, same build error is here again (somehow logical). Edit: same issue when cloning directly your master repository to my laptop. Edit2: strange, maybe something specific to my laptop config. It builds well using my android phone with termux. If you know of someone had same issue, let me know.

I don't see any reason why these errors would happen. All the dependencies are checked out in git so it's quite hard to have a problem here. Maybe you are on a old version that had a problem ?

For this kind of things, you can also the chat: https://gitter.im/the-git-bug/Lobby

Fixed by @seeduvax with https://github.com/MichaelMure/git-bug/pull/205 :tada:

Michael Muré (MichaelMure) closed the bug 6 years ago