Repository A: migrated to git from a project's SVN at revision r
: cloned the whole thing including all of SVN's history, tags, etc. A little development on git afterwards.
Repository B: the same project, but independently migrated from SVN at revision r+small_number
. Only the latest snapshot was brought into git. Lots of independent development afterwards.
Now I merged A into B. The idea is that SVN will be discarded, development will continue in the develop
branch of the project's repo on GitHub. I used simple merge to do the job; thankfully there were very few real conflicts . The development was mostly in different areas, though there was a lot of cleaning up after the merge, unrelated to git.
But: now when I do eg git rebase -i HEAD~2
on the merged result , which I understand should let me rebase the last two commits, I am greeted with a page of some 300+ commits -- the complete history of the project since revision 1 in SVN . I aborted the rebase for fear of messing up even more (obviously I'm a complete Git novice).
Is that outcome expected? Is it desirable? If not, how to fix it?
Note that all unit tests etc. pass, the files themselves are ok, only I don't understand what happened to git metadata/history.
EDIT: this is what I * think * the repository looks like now:
r A
... o --- o --- ... o
\
B \
o --- .... o ---- o --- ... o
r+small_number C HEAD
I guess this behaviour occurs because you are trying to rebase over a merge commit.
For the following answer, I'm assuming that your history looks like this, ie repositories A and B are completely independent:
r A
... o --- o --- ... o
o ... o
r' B
You need to ask yourself what are you trying to achieve? So you want to have a new branch C containing both the changes in A and B. What are the priorities here? Do you want to achieve a proper history; correcting the fact that r'
lost its SVN history? Or is it important to keep the git history of A and B unchanged?
My answer is going to assume you want to achieve the former. As both A and B descendet from very similar versions of the SVN repository, it might be a good idea to give them a common git base before merging the common history. So, ideally before merging you would have the situation:
r A
... o --- o --- .... o
\
\
o --- .... o
r+small_number B
At the moment, I'm not sure which is the best way to achieve this, but you could try doing git rebase -p --onto r --root B
.
Then you could just git merge
A and B and end up with the history
r A C
... o --- o --- .... o --- o
\ /
\ /
o --- .... o
r+small_number B
where C contains all your changes. I would probably leave it at that; without any further rebasing.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.