From: "David J. Bakeman" <nak...@comcast.net>
On 01/14/2017 10:24 PM, Jacob Keller wrote:
On Fri, Jan 13, 2017 at 6:01 PM, David J. Bakeman <nak...@comcast.net>
wrote:
History
git cloned a remote repository and made many changes pushing them all to
said repository over many months.
The powers that be then required me to move project to new repository
server did so by pushing local version to new remote saving all history!
Now have to merge back to original repository(which has undergone many
changes since I split off) but how do I do that without loosing the
history of all the commits since the original move? Note I need to push
changes to files that are already in existence. I found on the web a
bunch of ways to insert a whole new directory structure into an existing
repository but as I said I need to do it on top of existing files. Of
course I can copy all the files from my local working repository to the
cloned remote repository and commit any changes but I loose all the
history that way.
Thanks.
If I understand it.. you have two remotes now:
The "origin" remote, which was the original remote you started with.
You have now a "new" remote which you created and pushed to.
So you want to merge the "new" history into the original tree now, so
you checkout the original tree, then "git merge <new-remote>/<branch>"
and then fix up any conflicts, and then git commit to create a merge
commit that has the new history. Then you could push that to both
trees.
I would want a bit more information about your setup before providing
actual commands.
Thanks I think that's close but it's a little more complicated I think
:<( I don't know if this diagram will work but lets try.
original A->B->C->D->E->F
\
first branch b->c->d->e
new repo e->f->g->h
Now I need to merge h to F without loosing b through h hopefully. Yes e
was never merged back to the original repo and it's essentially gone now
so I can't just merge to F or can I?
a quick bikeshed..
You have both repositories, so nothing is lost.
Do note that 'e' commit sha1 in the first branch will be different from the
sha1 of 'e' commit in the new repo, but both should have the same top level
tree if they are truly identical.
You can fetch both repositories into a single common repo so you will have
an --orphan branch of the new repo.
Consider adding a --allow-empty commit e' to the original repo to note what
happens next (and how to do it), which is to use the replace mechanism to
bridge the gap between the e of the old repo and the e of the new repo by
making e of the new repo replace the e' you just created.
This will make it look like 'h' is the natural development of 'a'. Even if e
& e were not tree-same, you will be able to see a diff. You can now merge
'h' onto 'F' in whatever way you find appropriate to give the right view of
the development.
When you push this back upstream, note that the 'replace' is local, so
upstream sees a gap, but that commit e' has the instructions to rebuild the
link, should others require it (you may have to push the e' commit
separately).
--
Philip
