Diff on bitbucket pull request does not show code

Question

Hello !

One of our admins performed a 'git gc aggressive' on the bitbucket server. This had cleaned up all intermediate commits in various pull requests.

Though we were able to restore those deleted commits, the 'diff' tab on pull request still does not populate the code. Any suggestions on how this could be fixed ?

Note: The intermediate git commits were listed in ".git/logs/stash-refs/pull-requests/<number>/from". I checkout a temporary branch with each of those commits & pushed to the upstream repository to get it restored in bitbucket.

Bryan Turner · Answer

@builder, You're pretty deep into dark, dark territory. I can provide you with some insight, but to a certain extent the answer distills down to: "Sysadmins should never interact with Bitbucket Server's repositories on disk, especially not without consulting with support first. Some data, once lost, can't really be restored." With that said, though, all hope may not be lost. Your comment indicates you restored the commits listed in "logs/stash-refs/pull-requests//from", but that won't really do anything to help Bitbucket Server's pull request diffs because that's not what we show (more details on our diffs). What you need to restore is the commits from "logs/stash-refs/pull-requests//merge", which contains the "dark merges" Bitbucket Server created to show various iterations of the pull request's diff. If you _can't_ restore those because no one has them (and it's quite likely that's the case), the other option is to delete "stash-refs/pull-requests/" directly on the server for the affected pull request. * This cannot be done remotely * You should be extremely selective and very careful about which pull requests you do this for; try one, refresh the pull request in the UI and verify that the diff is shown * You're likely to lose context for comments by doing this, but it will at least make the diff visible again * You should also delete "logs/stash-refs/pull-requests/" if you delete "stash-refs/pull-requests/" to ensure it's not listing stale data My recommendation would be to create a support case so you can work with our support engineers to try and move things forward; there may be data involved in getting to the best possible state that you don't want to share here. Best regards, Bryan Turner Atlassian Bitbucket P.S. "git gc --aggressive" is a very blunt instrument and something that should never be run on a Bitbucket Server repository. (Or really any repository, for that matter; there are ways to achieve far better results if reducing disk usage is the goal.) Bitbucket Server expects to manage its repositories itself (and 5.x versions include significant improvements to how GC is managed), and running manual GC (especially aggressive GC, which almost certainly isn't doing what one might expect/intend) is likely to result in wide-ranging, and often quite subtle, problems with repositories, especially in organizations that use forks.

builder_rjq8ik · Answer

Thanks for your response @Caterina Curti,

However it took a few days for us to identify the issue. Quite a few additions were made to the database (new code changes, merge requests, etc.. ) and restoring from the backup would clean them out.

Do we have another option to restore the pull requests ?

thanks !!

Caterina Curti · Answer

Hi @builder,

I would highly recommend performing a full restore of Bitbucket Server (including the database and the filesystem) using a backup created before the git gc was performed.

This is the most efficient and safe way to entirely recover the status of the repository.

Is that an option for you?

Cheers,

Caterina - Atlassian