Re: merge maintaining history

["Philip Oakley" <philipoakley@iee.org>]

From: "David J. Bakeman" <nakuru@comcast.net>
> On 01/14/2017 10:24 PM, Jacob Keller wrote:
>> On Fri, Jan 13, 2017 at 6:01 PM, David J. Bakeman <nakuru@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