It's odd to me that the .git
directory would not have been restored in your backup. From a perspective outside git, the files in this directory are no different from any other files. I would want to be sure I understood the reason for that before deciding what to do next.
But since you refer to the "updated local repository", I'll assume you've already taken steps to create a new git repo at the local path, regardless of what was going on before[1]. In that case, you presumably have something like this:
On Bitbucket
A -- B -- C -- D <--(master)
Locally
E -- F <--(master)
I'm assuming that the first commit in your new repo is a newer state of the directory, compared to the last commit that was saved in BitBucket.
So the first thing to do is to configure the bitbucket repository as a remote
git remote add origin url://of/remote/repo
where the URL is the same one you would use for cloning. Then
git fetch
and you have locally
A -- B -- C -- D <--(origin/master)
E -- F <--(master)
Next you need to re-parent
E
onto D
. See the git filter-branch
docs (https://git-scm.com/docs/git-filter-branch), specifically relating to the--parent-filter
option. There are several examples showing different ways to accomplish this task.
[1] If I'm misreading your statement, and you haven't yet recreated the local repo, that's actually simpler, because that means there's no local history to be grafted in. In that case, you could do something like
cd /path/of/local/repo
git clone -n url://of/remote/repo old-repo
mv old-repo/.git .
rmdir old-repo
Then stage and commit your current state. It's a bit of a kludge, transplanting the .git
folder like that; but it seems to work in my tests and I know of no reason it should fail.