CODEWITHSUNDEEP
gitversion-controlgit-push
Lanny Heidbreder
Lanny Heidbreder

Reputation: 1403

Git "force push" from new local repo to remote, but keeping remote commit history

I have a working, live website that I am certain has the latest, correct version of every file, that is not managed with Git. I also have a Bitbucket Git repo that's ostensibly for that site, but that has major problems and out-of-date stuff in it.

What I want to do git init the live files, then somehow push them to the remote so that the final remote HEAD state is exactly like the state of my live files, but also so that the remote commit history remains intact.

I want to do this so that the live working tree is never in a different state. I've thought of creating a new branch, pulling remote the master, and then force-merging them or whatever, but as far as I know, I would have to check out the master branch and mess up the live files for those brief moments before and during the merge, assuming that everything went correctly.

I also thought of just FTPing the files down, working out all the conflicts/merging on my local computer, and then pushing from there to Bitbucket and pulling down to the live repo. But that also feels unreliable and risky.

I know that I should never manipulate live code like this, but this is the situation I've been dropped into, and I just want the easiest/safest way to make it work.

(I'm sure this is a duplicate question, but my Google-fu is failing me; please be gentle when directing me to previous answers.)

Upvotes: 8

Views: 1697

Answers (3)

Anshul Goyal
Anshul Goyal

Reputation: 76837

I think this should be simple to achieve with some manipulation of the .git directory.

Create test setup

cd ~/Desktop/test/
mkdir outdated server
cd outdated && touch testfile1 testfile2 testfile3
git init && git add . && git commit -m "testfiles"
cd .. && git clone --bare outdated/ cloud_hosted_repo

So far, we have cloud_hosted_repo which should be equivalent to a github repo, outdated directory which should be treated equivalent to a locally checked out copy of the github repo code (say on a developper machine), and a server directory which should we will treat as the remote server.

Login to the server and creating the deployed project on the server

cd server && mkdir project_location some_other_location
cd project_location/ && touch testfile4 testfile5 testfile6 && cd ..

If this project location is already a git repo, move the .git directory

mv project_location/.git project_location/.git.backup

Clone the original repo to some location and clear the files from it

cd some_other_location/ && git clone ../../cloud_hosted_repo/ .
git rm "*" && git commit -m "removed all older files" && cd ..

Move around the .git repo

mv some_other_location/.git/ project_location/ && cd project_location/
git add . && git commit -m "Updated Project" && git push origin master

And we are done.

git log will reveal all the commits in the branch.

You can throw in additional complexities (like creating extra branches for backups etc) wherever you need.

Upvotes: 0

mrutyunjay
mrutyunjay

Reputation: 8250

Try git merge -s.

git merge -s ours origin/remote_branch

This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches.

Upvotes: 3

Simon Boudrias
Simon Boudrias

Reputation: 44589

If you're sure that the files online are up to dates and that the files on repo follow the same history, you should checkout the current Git history. And simply copy paste the content of the FTP over these files.

Then you'll be at the lastest version from the FTP and the changes made online will apply on top of the current Git history.

But sure, this is "risky" procedure if you're not sure the two code base have diverged. But you can't do nothing about that because without the online files history, you can't make a three-way merge (only two way).

So, from there. I'd review the diff line by line to make sure. If you're in doubt about wheter the history diverges, there's really no way around that manual task.

Upvotes: 0

Related Questions