I'm working on a project where the original developer created .tar.gz's for each new release. I took the latest release, put it in .git, and add my patches atop of it.
After many commits and changes over the past few months, the old developer has asked me to become the maintainer and put it on github. I would like rebase so all old .tar.gz releases exist as a single commit, and then place my commits on top of those to keep the old releases in git history but maintain my existing commit history.
(Since this is the first ever commit to be pushed publicly via git, I don't care about clobbering the git-hash history with rebase.)
This explanation has two .git trees: the old historical tree with single-commit .tar.gz's that I call "historical" and another that I call "new" with my commits that need to show up on top of all historical commits. To do this I tried the following:
git init
git remote add historical /path/to/historical-tree
git checkout -b before-historical-rebase
git rebase historical
I thought since the end of the last .tar.gz was the same as the beginning of my first commit that this would be clean, but either my commit history at the border of the last .tar.gz version and my first commit isn't as clean as I thought or there is a better way to do this.
How would you approach this?
If I understood correctly :
* eacfdd14 (HEAD -> master) commit
* eabddd13 commit
* eaacdd12 commit
* ea0bdd11 2.2 latest version from tar.gz
* cd22dfaf (historical) 2.2 latest version from tar.gz
* cd21dfae 2.1 version from tar.gz
* cd20dfad 2.0 version from tar.gz
* cd11dfac 1.1 version from tar.gz
* cd10dfab 1.0 first version from tar.gz
To avoid replaying your initial "2.2 latest version from tar.gz" commit, use git rebase
with the following arguments :
git rebase --onto historical ea0bdd11 master