I have a GitHub repository shared with a number of contributors with a relatively long commit history. At some point, I attempted to merge an orphaned branch into the master branch, which didn't work out quite as expected. The result of this attempt is that ever since this merge, all files in the repository appear to have been (re)created in this commit. The commit history tree is still preserved, so at the time I didn't pay too much attention to it (I was more than happy that I finally got this merge to work).
Something I did not realise back then, was that the history of individual files was not preserved. See for instance this example: this file should have a history that goes all the way back to 2012, but this history is not shown past 11 August 2017, when I merged the orphan branch.
If I look at the history tree, I see this rogue commit dangling like some kind of appendix, indicated in green in the figure below. Normally it would not be possible to safely rebase
commits that have already been pushed upstream, without causing mayhem to everybody else. But in this particular situation, would it be possible to either merge or delete this dangling commit, so that the individual file history is recovered? Or is there another solution to safely re-route the version history?
You should be able to just add a parent to orphan. (this sounds so weird out of context)
First, choose a parent, then replace the commit with git replace --graft
git replace --graft b1fbc1d21933 de3df2f048c
Make sure all is good, git replace will not write any changes, but it should all be good on your instance now. You can even check the new commit with
git for-each-ref
If you have your history back and are happy with the result, write the changes with
git filter-branch -- --all
And force push your new history.
Disclaimer: I have tested this with your repo and it seems to be working fine, but I have never actually done something like this before, it might do unwanted things.