# Using non-bare repositories **URL:** \ **Category:** Install/Maintain/Configure\ **Created:** [December 10, 2019, 5:40pm UTC](https://forum.gitea.com/t/using-non-bare-repositories/1716 "2019-12-10T17:40:02Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![lukastribus](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/lukastribus/32/720_2.png) [@lukastribus](https://forum.gitea.com/u/lukastribus)\ **Post date:** [December 10, 2019, 5:40pm UTC](https://forum.gitea.com/t/using-non-bare-repositories/1716/1 "2019-12-10T17:40:02Z")
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? ---
**Author:** ![techknowlogick](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/techknowlogick/32/4706_2.png) [@techknowlogick](https://forum.gitea.com/u/techknowlogick)\ **Post date:** [December 11, 2019, 6:45am UTC](https://forum.gitea.com/t/using-non-bare-repositories/1716/2 "2019-12-11T06:45:48Z")
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. ---
**Author:** ![lukastribus](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/lukastribus/32/720_2.png) [@lukastribus](https://forum.gitea.com/u/lukastribus)\ **Post date:** [December 13, 2019, 5:33pm UTC](https://forum.gitea.com/t/using-non-bare-repositories/1716/3 "2019-12-13T17:33:49Z")
Thanks, I will research this. ---
**Author:** ![lukastribus](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.gitea.com/lukastribus/32/720_2.png) [@lukastribus](https://forum.gitea.com/u/lukastribus)\ **Post date:** [December 30, 2019, 11:56am UTC](https://forum.gitea.com/t/using-non-bare-repositories/1716/4 "2019-12-30T11:56:09Z")
As the API has been improved to support my use-case ([bugfix](https://github.com/go-gitea/gitea/issues/9294) and [feature](https://github.com/go-gitea/gitea/issues/9462)), I can work with the gitea API directly on the bare repository instead, which is way easier.