Strange merge issue

Hoping to get some guidance on a strange issue that we are having.

This MR:

…shows that the merge completed, pipeline tasks were successful and the merge was performed. However, we cannot find the actual commits in the git repo.

Other than someone deliberately going in and modifying the repo to remove the commits, is there anything else that could have caused this scenario?

Cheers,
Ralph

Hi @skelband

I can’t quite answer you question, but I can tell you how to retrieve your commit.

If I clone your repo and look for that commit I get fatal: bad object db27ee2135438a6fe52729ca559c12d3c718e853, but is the commit in the repo?

The MR page shows this text:

Merged by Ordissimo 10 hours ago (Mar 29, 2021 2:29pm GMT+0100)10 hours ago

The changes were merged into master with db27ee21

The source branch has been deleted

If you click on the commit SHA you’ll get to this page, which tells you that the parents of that commit on master are 0ef485d1, which is a merge commit, and 6cb6741c which is the one you are looking for. So far so good.

Your project graph shows one of the parent commits lide70: more white balance, less slope tables on master, but not the commit itself.

If you search for the SHA of the commit you are looking for, and select the Begin with the selected commit checkbox you’ll see this graph which shows the commit, the parent merge commit (Merge branch 'fix-stuck-75dpi' into 'master'), and also shows that the HEAD of your master is behind those two commits.

In case the graph changes before you see this, here’s a screenshot:

So, GitLab the commit still exists, just not where you’d expect it to be in the history.

How do you get hold of that commit locally? You can fetch it directly (rather than fetching the branch) and check it out:

$ git fetch origin 6cb6741ce2f94c98ff25088da193aab73de07a02:refs/remotes/origin/orphaned-commit 
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), 26.62 KiB | 8.87 MiB/s, done.
From gitlab.com:sane-project/backends
 * [new ref]             6cb6741ce2f94c98ff25088da193aab73de07a02 -> origin/orphaned-commit

$ git checkout 6cb6741ce2f94c98ff25088da193aab73de07a02
Note: switching to '6cb6741ce2f94c98ff25088da193aab73de07a02'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 6cb6741ce Save resolution.

$ git log

commit 6cb6741ce2f94c98ff25088da193aab73de07a02 (HEAD, origin/orphaned-commit)
Author: Thierry HUCHARD <thierry@ordissimo.com>
Date:   Sun Mar 28 20:33:56 2021 +0200

    Save resolution.

...

From there you could cherry-pick the commits you need back to another branch.

I’m not sure how helpful that is, since it doesn’t really prevent the problem happening again…

Sarah

Thanks for that. I will look into a fix for that in the morning. Very strange indeed.

Is there a “safe” way to just delete that commit?
The changes in the commit are trivial so we could just re-apply them in a new commit.

I can’t see why not, but I’m not really sure whether commits like this will be garbage collected anyway. You might try something like this:

rm -rf .git/refs/original/*
git reflog expire --all --expire-unreachable=0
git repack -A -d
git prune

or it might be safer to use GitLab’s built in housekeeping command, which does much the same thing.

I have also been looking through your project activity and found something interesting. Here is the merge request being merged into master:

which is much as you would expect. But before that, the same two commits were pushed directly to master:

I could not find a force-push to master that would have deleted the original Save resolution commit, so I wonder if that has caused your problem?

You can protect master to prevent anyone pushing to it (rather than merging), which might help.

Hmmm. Yes the user thought he might have done something iffy. I have just kicked off the Housekeeping job. Perhaps that will excise the offending commit. In any case, it sounds like it is not going to affect the general running of the project. I was more worried that the repo was broken.

Thanks very much for you assistance!

1 Like