Using non-bare repositories

Install/Maintain/Configure
1

Hello,

I’m a little confused whether non-bare repositories are supported in Gitea and how to use them.

Gitea used to have a is_bare flag in the database, which suggests that both bare and non-bare repositories are or at least used to be supported?

Why I want to use non-bare:
I want to use non-bare repositories because I need to commit something locally from scripts but at the same time I need gitea to do it’s magic (like accepting pull requests). I need to be able to commit new and changed files via script (git commit), without manual intervention. I also don’t want any merge commits (non-FF).

I would use the Gitea API to commit the changes directly to Gitea, but as opposed to git commit it does not support setting author date and commit date, which is a hard requirement.

I cannot just automatically “push” the changes to gitea with a post-commit hook, because that would fail if the Gitea bare repository changed in the mean time.

I just want a single repository I can work with (so it’s needs a working tree) and uses Gitea as well - that’s why I want to use non-bare repositories in Gitea.

What I tried:
I am using Gitea 1.10.1 (mysql) with git 1.9.1:

  • when I create a new repository from Gitea UI, it is bare (obviously). There is no option to create a non-bare repository
  • when I manually create a non-bare repository in a destination path that Gitea will later use, and create the repository from Gitea afterwards, I get a HTTP 500 error and Gitea will delete the entire directory
  • when I create the repo within Gitea and replace the directory with a non-bare repo, when recreating hooks, Gitea will assume this is a bare reprository and install the hooks in ./hooks/ as opposed to .git/hooks/ (for a non-bare repository).

Can anyone shed some light on this?

2

the is_bare column was not what you thought, it was later corrected to be is_empty so that when looking at the database it could be understood correctly. Gitea uses bare repos only.

The gitea project uses a CI to push git changes back to the project when specific files need to be changed and adds a skip ci message so that the CI doesn’t end up in a loop. Perhaps this approach may work for you.

Using the repo files directly without involving Gitea will create an inconsistent state and will end up causing you issues.

1 Like
3

Thanks, I will research this.

4

As the API has been improved to support my use-case (bugfix and feature), I can work with the gitea API directly on the bare repository instead, which is way easier.