Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Diff on bitbucket pull request does not show code

builder
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 15, 2018

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. 

1 answer

1 vote
Caterina Curti
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 15, 2018

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

builder
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 18, 2018

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 !!

Bryan Turner
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 18, 2018

@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/<number>/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/<number>/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/<number>" 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/<number>" if you delete "stash-refs/pull-requests/<number>" 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.

Like Dustin Gläser likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events