Re: merge maintaining history

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



W dniu 19.01.2017 o 22:42, Junio C Hamano pisze:
> "David J. Bakeman" <nakuru@xxxxxxxxxxx> writes:
 
[...]
>> 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?
> 
> With the picture, I think you mean 'b' is forked from 'B' and the
> first branch built 3 more commits on top, leading to 'e'.
> 
> You say "new repo" has 'e' thru 'h', and I take it to mean you
> started developing on top of the history that leads to 'e' you built
> in the first branch, and "new repo" has the resulting history that
> leads to 'h'.
> 
> Unless you did something exotic and non-standard, commit 'e' in "new
> repo" would be exactly the same as 'e' sitting on the tip of the
> "first branch", so the picture would be more like:
> 
>> original A->B->C->D->E->F
>>              \
>> first branch  b->c->d->e
>>                         \
>> new repo                 f->g->h
> 
> no?

On the other hand Git has you covered even if you did something 
non-standard, like starting new repo from the _state_ of 'e', that
is you have just copied files and created new repository, having
'e' (or actually 'e*') as an initial commit.

   original A<-B<-C<-D<-E<-F
                \
   first branch  b<-c<-d<-e

   new repo               e*<-f<-g<-h

Note that arrows are in reverse direction, as it is newer commit
pointing to its parents, not vice versa.

Assuming that you have everything in a single repository, by adding
both original and new repo as "remotes", you can use 'git replace'
command to replace 'e*' with 'e'.

   original A<-B<-C<-D<-E<-F
                \
   first branch  b<-c<-d<-e
                           \
   new repo                 \-f<-g<-h
   (with refs/replace)

>     Then merging 'h' into 'F' will pull everything you did since
> you diverged from the history that leads to 'F', resulting in a
> history of this shape:
> 
>> original A->B->C->D->E->F----------M
>>              \                    /
>> first branch  b->c->d->e         /
>>                         \       /
>> new repo                 f->g->h

Then you would have the above history in repositories that fetched
refs/replace/*, and the one below if replacement info is absent:

   original A<-B<-C<-D<-E<-F<-----------M
                \                      /
   first branch  b<-c<-d<-e           /
                                     /
   new repo               e*<-f->g->h

But as Junio said it is highly unlikely that you are in this situation.

HTH
-- 
Jakub Narębski




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]