Re: Git migration status upate

[Kristian Høgsberg <krh redhat com>]

On Tue, 2009-03-17 at 16:36 +0100, Santi Béjar wrote:
> 2009/3/17 Xavier Claessens <xclaesse gmail com>:
> > Le mardi 17 mars 2009 à 11:07 -0400, Behdad Esfahbod a écrit :
> >> On 03/17/2009 06:25 AM, Xavier Claessens wrote:
> >> > Hello,
> >> >
> >> > First I would like to thanks all volunteers that worked to prepare the
> >> > git migration. Really good job!
> >> >
> >> > Now that 2.26.0 is out, I would like to know what's the plan for the
> >> > official migration? Is there any chance 2.27.1 will be made out of git?
> >> > Do we have a diplomatic strategy to "force" that migration whatever will
> >> > be said on d-d-l? Shouldn't we announce as soon as possible that the
> >> > migration will happen rsn, so maintainers that are not used to git yet
> >> > can start training instead of hoping that git will never happen for
> >> > GNOME?
> >> >
> >> > Finally, as maintainer of Empathy, we are already doing all the dev on
> >> > git, using the terrible git-svn... That means that lots of contributors
> >> > have pretty large branches on git only. Is it possible to be warned 1 or
> >> > 2 days before the migration so we push everything in SVN branches and
> >> > get that code migrated. Otherwise all our branches will be
> >> > incompatible... In such situation I guess the only way is to export
> >> > every commit as patch and apply back on the new repository, right?
> >>
> >> I'm sure you can fetch the old and new tree into one repository and rebase the
> >> branches over the new master.
> >
> > I don't think so, because the 2 svn imports will be completely different
> > commits. You can cherry-pick commits from 2 git-svn checkouts of the
> > same svn repositoy.
> 
> I think you can do it even with completely different history,
> something like this:
> 
> git rebase --onto newmaster oldmaster topic
> 
> that basically means: take all the commits in the range
> oldmaster..topic and rebase them on top of newmaster.
> 
> There is a section in the rebase manpage discussing this: "RECOVERING
> FROM UPSTREAM REBASE".

Yes, something like that should be possible.  As Behdad mentions, you
can fetch (not pull) a completely different repo into your git repo and
then use git rebase as Santi describes to pull your changes from the
git-svn repo into the GNOME git repo.  We can figure it out - all the
history is upstream and in your repos and we can piece it back together.
Just don't merge the svn branches, it won't record the merge points and,
who knows, maybe the branch isn't ready to be merged yet :)

cheers,
Kristian