Git: Trying to retrace squashed commits on a deleted branch - is it possible?

user_949283 0
Viewed 78

Sometime in the past 6 weeks an issue has been introduced into the codebase. I have identified which branch introduced it (and the head/tail commits for that branch) but I would now like to start tracing through the individual commits on that branch to identify the exact cause.

My problems are that:

  1. The branch in question was deleted by the build-server after being merged to master
  2. Before merging, the commits were squashed (by the build server).
  3. I don't have access to the local environment where the commits were originally made and pushed from.

I can see the commit history for the now-deleted branch on our build-server but if I try to checkout one of them locally I just get the error

error: pathspec '<commit-id>' did not match any file(s) known to git

The build-server is also happy to show me the diffs for each commit which implies they are still in git somewhere (or alternatively the build-server has cached them, but that seems unlikely).

I've seen references to git reflog but that seems only to work on the local repository history (or, more likely, I've failed to find some advanced option it offers).

Is there a way to do this? TIA.

git
1 Answers

I can see the commit history for the now-deleted branch on our build-server...

Log into the build server, and create a new branch from the latest commit ID before the squash and push it:

git branch investigation-branch 1234abcd # use the last commit id before the squash
git push origin investigation-branch # assuming your remote is "origin"

Now fetch from your local machine and you should be able to see that branch as it was previously. You can simply delete the branch on the remote when you're done investigating, if you wish.

Note: if you prefer not to log into the build server, it's possible that another machine has the commits too. The places that might still have them are:

  1. The original machine that pushed the commits. (Already ruled out that you can't access this.)
  2. The build server. (Confirmed.)
  3. Any machine that fetched the repo during the time window where those commits existed on the branch and haven't been garbage collected yet. The longer the desired commits existed on the branch before getting squashed, the greater the probability that they were fetched by another machine. Note the default garbage collection for orphaned commits is 90 days so 6 weeks ago is well within the default time window, though it's possible to manually run commands to clean up your local repo and blow away those orphaned commits sooner.
  4. Do you use a centralized Repository? If yes, it should still have a copy of the unreferenced commits and there may be a mechanism for accessing them. Some tools even allow you to create a new branch from any historical commit, directly from the UI. This would essentially accomplish your goal without having to log into the server to do it manually.
user_1845460
Related