Ok, when I said you had two branches, I want to mean we can look at
your two SVN repositories as two separate branches. My mistake.

If you do not want the crash to be visible in the history, you can try
to replace the step 6 with a rebase on the mergeCrash's postCrash
branch, followed by the merge on the mergeCrash's master branch. This
will make the history linear, and the postCrash branch will not be
visible in the master history. I'm not sure the rebase will work, as
the two branches don't share a common parent.

If the rebase doesn't work, you can try to extract each commit from
the postCrash repository as patches and apply them on the mergeCrash

On Sep 6, 3:47 pm, Mark Kharitonov <mark.kharito...@gmail.com> wrote:
> @Rouleau: Thanks for the reply.
> Nope. I have two SVN repositories, where:
> - the first repository is the repository before the old VCS crashed.
> - the second repository contains all the dev code since the crash with
> the history starting from the crash day onwards.
> I wish to have a single GIT repository containing the merge of the two
> SVN repositories, so that the crash incident does not manifest itself
> in anyway. In other words, if a file is present in two SVN
> repositories, then it has two distinct histories - the one from its
> creation until the crash (in the first repo) and the other  - from the
> crash until now (in the new repo). I want this file to have a single
> history in the GIT, which is from its creation until now.
> On Sep 5, 6:31 pm, P Rouleau <proulea...@gmail.com> wrote:
> > I'm not an expert, but it looks like you now have two branches in SVN
> > and you want to merge them back, but in git instead. And the hardest
> > step will be "finding the time to do it"...
> > I understand you want to keep the pre-crash history and the post-crash
> > one too. I suggest these steps (look at the doc for the options'
> > description):
> > 1. git svn clone [-s] -A {authors.lst} svn://pre-crash-svn mergeCrash
> > 2. git svn clone [-s] -A {authors.lst} svn://post-crash-svn postCrash
> > 3. cd mergeCrash
> > 4. git remote add postCrash ../postCrash
> > 5. git fetch [--tags] postCrash master
> > 6. git merge postCrash/master
> >     If you did a lot of modifications in the post-crash branch, this
> > is where you will regret it. You will probably use --continue alot.
> > 7. git add {conflictedFiles}
> > 8. git commit -m "Back to one history, at last"
> > 9. git remote add origin g...@thegitserver:project.git
> > 10. git push [--tags] origin master
> > 11. // start working with the new server and shutdown the SVN ones to
> > avoid creating a new mess.
> > If step 6 is too challenging, you can simply push the preCrash history
> > into a preCrash branch on the new server and simply push the postCrash
> > history to the master branch and continue to work from there. You will
> > have access to the old history, but it will not be very useful. I'm
> > not sure, but if you have many branches, you will have to push them
> > also.
> > PS: I did not try the steps myself. I have only writed the steps I
> > would have plan to do. We have switched from SVN to git not long ago
> > and it went very well, but we only had to do step 1, 9 and 10.
> > On Sep 5, 3:42 am, Mark Kharitonov <mark.kharito...@gmail.com> wrote:
> > > Dear ladies and sirs.
> > > We use SVN as our VCS, but wish to migrate to git. All is good, but a
> > > few months ago our SVN server had a serious RAID problems (so much
> > > that it became unusable) plus at the same day no IT person was
> > > available to restore the repository from the backups. So, we have
> > > setup a temporary SVN server on a certain workstation from the most
> > > recent version that we had. The net result is:
> > >    1. We have a few months of work on the temporary SVN server (the
> > > revisions there start from 1, of course)
> > >    2. There is a new VCS server machine with the pre-crash SVN
> > > repository restored there, but no one uses it yet, because someone has
> > > to merge the temporary repository there somehow and no one has the
> > > time.
> > >    3. In addition, we want to migrate to git, because SVN is just too
> > > much pain to work with - merges are killing us.
> > > Can anyone advice on the best process to end up with a git repository,
> > > which would contain the old SVN repository merged with the temporary
> > > one?
> > > BTW, the new VCS server is a linux machine.
> > > Thanks a lot in advance.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to