4

We have our own GitLab server running and have imported an older project into it. This project has a strange behavior, which seems not to be the default for projects on the gitlab.com server: If a merge request requires a local rebase, it is not possible to force push git push —force-with-lease to the remote branch after the rebase.

! [remote rejected]     feature_branch -> feature_branch (non-fast-forward)
error: failed to push some refs to 'server.de:group/project.git'

The remote branch is unprotected, and the force push should work in principle. It seems not related to any GitLab configuration but the configuration of the old GitLab project.

Does anyone know how to reconfigure the remote configuration? I don't even know what to look for. A colleague of mine found this answer here:

https://www.reddit.com/r/git/comments/50td21/comment/d76urb5/

But I don't find (can't read) this file on the remote server. Any help would be appreciated.

Kokookster
  • 43
  • 4
  • Are you [sure `force-with-lease` is what you need](https://stackoverflow.com/a/52823955/5747944) in this case and not a regular force push? – sytech Sep 13 '22 at 19:34
  • In addition to protected branch rules, also check for push rules in the repository settings that may be preventing the push (settings -> repository -> push rules) – sytech Sep 13 '22 at 19:43
  • Hi @sytech, thanks for your suggestions. Unfortunately, a regular force push does not work either. We also don't have the push rules section. As far as I understand from the docu this is only available for GitLab premium. – Kokookster Sep 14 '22 at 07:57
  • Could you tell us exactly what you did? Best would be sequence of commands. – tukan Sep 16 '22 at 08:40

2 Answers2

3

Unless the logs include any clue, you need to check the configuration in the remote repository on your on-premise GitLab server, in the folder referenced by your repository storage (for instance /home/git/repositories/...).

cd /home/git/repositories/<namespace>/<myRepo.git>
git config -l
# with a recent enough Git
git config -l --show-scope --show-origin

Check if you have any settings which might prevent the push, like receive.denyNonFastforwards.

git config --show-scope --show-origin receive.denyNonFastforwards

The OP confirms in the comments

First, I had to understand that all project paths were hashed and can be found under /var/opt/gitlab/git-data/repositories/@hashed.
The hashes are in the UI admin area under the corresponding project.

Using the hashed path, I found the config file with denyNonFastforwards.
I changed that using git config --file config receive.denynonfastforwards false.

However, this changed the owner to root, and no pushes worked at all.
So I had to change back owner to git by using chown git: config. After that, everything worked as expected.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    @LeGEC Thank you for your feedback. I have edited the answer accordingly. – VonC Sep 19 '22 at 05:59
  • Thanks! That has helped. I needed to find the storage, because it was configured to use hashed pathes. Indeed, there is a `denyNonFastforwards` set in the config file. However, any `git` command does not give an output. What would be the savest way to change this configuration? – Kokookster Sep 21 '22 at 08:16
  • Ok, I used `git config --file config [...]` to change it. However, this also changed the permissions. I had to set it manually afterward. But now it works! Thank you again! – Kokookster Sep 21 '22 at 09:10
  • @Kokookster Great, well done! (sorry for the delay, I was away from the keyboard for a bit). What exact command did you ending up using in the end? – VonC Sep 21 '22 at 12:26
  • First, I had to understand that all project paths were hashed and can be found under `/var/opt/gitlab/git-data/repositories/@hashed`. The hashes are in the UI admin area under the corresponding project. Using the hashed path, I found the `config` file with `denyNonFastforwards`. I changed that using `git config --file config receive.denynonfastforwards false`. However, this changed the owner to `root`, and no pushes worked at all. So I had to change back owner to `git` by using `chown git: config`. After that, everything worked as expected. – Kokookster Sep 28 '22 at 07:45
  • @Kokookster Thank you so much for that feedback, very helpful. I have included your comment in the answer for more visibility. – VonC Sep 28 '22 at 08:08
-1

Under any circumstances you should never force a push on a remote git repository, you are risking to lose some changes you didn't have on your local machine.

As for the issue, it may be due to a fact that you're pushing to a different branch with unrelated histories, happens when you initialize git locally and the default branch is master but the remote branch when you make a new repository is main, so you can't push from this to that as it's unrelated history.

Ahmed Hani
  • 15
  • 4
  • 1
    it's ok to use `git push --force-with-lease` on a feature branch. You don't risk to lose any code, neither yours nor your teammates'. https://stackoverflow.com/questions/52823692/git-push-force-with-lease-vs-force – jackdbd Sep 20 '22 at 13:23
  • @jackdbd Didn't get a chance to try this but I got the idea, Thanks – Ahmed Hani Sep 20 '22 at 14:17