"David J. Bakeman" [off-list ref] writes:
quoted
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?
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? 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
If on the other hand you did something non-standard and exotic to
rewrite 'e' at the end of "first branch" and make a different commit
that does not even have any parent in "new repo", and the history of
"new repo" originates in such a commit that is not 'e', things will
become messy. But I didn't think I read you did anything unusual so
a simple "git checkout F && git merge h" should give you what you
want.
W dniu 19.01.2017 o 22:42, Junio C Hamano pisze:
"David J. Bakeman" [off-list ref] writes:
[...]
quoted
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:
quoted
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:
quoted
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
On 01/20/2017 03:37 AM, Jakub Narębski wrote:
W dniu 19.01.2017 o 22:42, Junio C Hamano pisze:
quoted
"David J. Bakeman" [off-list ref] writes:
[...]
quoted
quoted
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:
quoted
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)
quoted
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:
quoted
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
OK so what I've done so far is to clone the original then I added
another remote connected to new repo. Then I did git merge newrepo. It
did a bunch of stuff that flashed by really fast and then reported a
conflict. Now if I do a git st there are a bunch of files that seem to
be already added to a commit and all the files with conflicts which it's
says need to be fixed and added.
I'm still learning git even after using it for several years. I've
never really seen this before. So the already added files are the ones
that git was able to merge mechanically? If so can I diff those changes
some way? Would I have to un add (reset HEAD) all those files to see
the diffs? Would it have assumed that my changes are to be preferred?
Thanks again for all the great help!
On Wed, Jan 25, 2017 at 4:31 PM, David J. Bakeman [off-list ref] wrote:
OK so what I've done so far is to clone the original then I added
another remote connected to new repo. Then I did git merge newrepo. It
did a bunch of stuff that flashed by really fast and then reported a
conflict. Now if I do a git st there are a bunch of files that seem to
be already added to a commit and all the files with conflicts which it's
says need to be fixed and added.
I'm still learning git even after using it for several years. I've
never really seen this before. So the already added files are the ones
that git was able to merge mechanically? If so can I diff those changes
some way? Would I have to un add (reset HEAD) all those files to see
the diffs? Would it have assumed that my changes are to be preferred?
Thanks again for all the great help!
Try "git diff --cached" to show all the current differences saved in the index.
Thanks,
Jake