Re: [Qemu-devel] [RFC PATCH 1/1] OpenBIOS: Switch over to official OpenBIOS git repo

[Jeff Cody <jcody@redhat.com>]

On Wed, Jul 06, 2016 at 04:19:24PM +0100, Mark Cave-Ayland wrote:
> On 06/07/16 14:29, Jeff Cody wrote:
> 
> > On Wed, Jul 06, 2016 at 08:26:57AM +0100, Mark Cave-Ayland wrote:
> >> On 28/06/16 21:43, Mark Cave-Ayland wrote:
> >>
> >>> On 28/06/16 14:44, Stefan Hajnoczi wrote:
> >>>
> >>>> On Tue, Jun 28, 2016 at 7:11 AM, Jeff Cody <jcody@redhat.com> wrote:
> >>>>> On Mon, Jun 27, 2016 at 07:48:23AM +0100, Mark Cave-Ayland wrote:
> >>>>>> On 21/06/16 14:48, Mark Cave-Ayland wrote:
> >>>>>>
> >>>>>>> On 21/06/16 11:28, Stefan Hajnoczi wrote:
> >>>>>>>
> >>>>>>>> On Tue, Jun 21, 2016 at 01:40:42AM -0400, Jeff Cody wrote:
> >>>>>>>>> This update should preserve git history, and allow seamless switching
> >>>>>>>>> over to the official openbios git repo, rather than pulling from the
> >>>>>>>>> svn mirror.  All prior history from the svn repository should still be
> >>>>>>>>> preserved (i.e., commit hashes are the same for historical commits).
> >>>>>>>>>
> >>>>>>>>> In the roms/openbios submodule, the branch "origin/official" is the
> >>>>>>>>> latest mirror of the official git repository (fetched daily).
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Jeff Cody <jcody@redhat.com>
> >>>>>>>>> ---
> >>>>>>>>>  roms/openbios | 2 +-
> >>>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> Assuming the git.qemu-project.org openbios.git remote and .git/config
> >>>>>>>> mirror setting has been updated to use the new upstream git repo:
> >>>>>>>>
> >>>>>>>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> >>>>>>>
> >>>>>>> Is it possible to switch this around, so that there is a legacy branch
> >>>>>>> which points to the current HEAD and master points to the new, upstream
> >>>>>>> git HEAD? Then it means if someone clones either the
> >>>>>>> git.qemu-project.org repository or the official repository then the
> >>>>>>> default master branch will point to the same HEAD.
> >>>>>>
> >>>>>> Urgent ping? It has been another week, we're coming up to soft freeze
> >>>>>> and the PPC guys are urgently after an OpenBIOS fix.
> >>>>>>
> >>>>>> As per the above I'd really like the branches switched around so that
> >>>>>> both the git.qemu-project.org master and github.com master are exactly
> >>>>>> the same HEAD although I believe it may be technically possible to do
> >>>>>> this part separately once the HEAD switch is in? If so, please can we
> >>>>>> apply this and then I can line up and attempt to push the outstanding
> >>>>>> patches to the new github master later this evening.
> >>>>>>
> >>>>>
> >>>>> If we want something other than this patch, so that the openbios git repo
> >>>>> hosted on qemu.org has 'master' as the new github tracking, we might be able
> >>>>> to do that with a git-merge.  Here are the three methods I am thinking of:
> >>>>>
> >>>>>
> >>>>> A) For 'master' referencing new github hashes:
> >>>>>     git fetch github
> >>>>>     git merge --no-edit github/master
> >>>>
> >>>>
> >>>>>     git push /pub/git/openbios.git master:master
> >>>>>
> >>>>>
> >>>>> B) Old, prior behavior for SVN:
> >>>>>     git svn fetch svn
> >>>>>     git merge git-svn
> >>>>>     git push /pub/git/openbios.git master:master
> >>>>>
> >>>>>
> >>>>> C) Current behavior, as of the submitted patch above, this is what is being run:
> >>>>>     git svn fetch svn
> >>>>>     git merge git-svn
> >>>>>     git fetch github
> >>>>>     git push /pub/git/openbios.git master:master
> >>>>>     git push /pub/git/openbios.git official:official
> >>>>> (This seemed safest to run, as old behavior remains unchanged)
> >>>>>
> >>>>> If we do A), we'll have merge commits with just the auto-generated merge
> >>>>> message, and I'm not sure this is what you want.  Thoughts?
> >>>>
> >>>> No, I think A is not appropriate because the mirror must have the
> >>>> exact same commit IDs as github.  Only fast-forward merges are
> >>>> allowed, so I would use --ff-only instead.  The first time you begin
> >>>> using the github repo you'll need git reset --hard github/master to
> >>>> move from the old svn commit history to the new github history.
> >>>>
> >>>> It's important to keep the svm commits so old versions of QEMU still
> >>>> work.  You can ensure that the garbage collector does not delete the
> >>>> commits by tagging the latest svn head.
> >>>
> >>> Yes, this is exactly what I'm thinking. Given that the repository is
> >>> already merged, is it not just as simple as:
> >>>
> >>> git checkout master -b legacy
> >>> git checkout master
> >>> git reset --hard 36785d7
> >>>
> >>> And then change the nightly script to "git pull origin/master" with the
> >>> origin remote set to the github.com repository. I'm also fine with
> >>> asking existing developers to switch over to the new master once we're done.
> >>
> >> Urgent ping again?!
> >>
> > 
> > Is there anything that is actually holding your work up?  The server has all
> > the github hashes in it - the only thing that needs to happen is a checkout
> > from 'origin/official' in the submodule to use them.  Not to say figuring
> > out the best way to get those hashes on 'master' in the submodule can't
> > happen, but since the hashes obviously will be the same I don't think
> > anything should actually hold you up.  Or am I missing something?
> > 
> > Thanks, Jeff
> 
> Hi Jeff,
> 
> My understanding from earlier in the thread was that people wanted a
> single commit to move the OpenBIOS submodule over to use the new
> official HEAD but at the same time I was positing to also switch master
> so that the two repositories match each other moving forward.
> 
> The two main reasons being that i) everyone's favourite habit is to run
> "git checkout master && git pull" when trying to update a remote
> repository and so with the current setup I can see people
> building/testing off the wrong branch and ii) the repository at
> git.qemu-project.org has been recommended as the "official" git
> repository for a while and has more users than SVN.
> 
> Therefore if there is going to be a changeover period, we might as well
> do it in one go: I can email the OpenBIOS list and ask users to switch
> to the new repository, everyone manually rebases and then there is no
> confusion between repositories moving forward. Yes I agree that we could
> just switch the master HEAD in its current incarnation and carry on, but
> it is one of those things that the longer it gets left, the more likely
> there is to be confusion between repositories in the long-term vs.
> simply going ahead and getting it all out of the way.
> 
>

Alright, here is what I think will work to switch over relatively
painlessly, and move master over to the github hashes for the submodule.  

I haven't done it yet on the server, because I want to get another set of
eyes double checking it (Stefan, Mark).  However, I have mocked it up and
tested it locally, so I think it should work fine, unless there are
scenarios I missed.  Here are the step-by-step details:


Server side actions
=====================

1) In bare openbios.git repo (git://git.qemu.org/openbios.git):

    git tag svn-last-official 422b916
    git branch svn-head 422b916
    git branch -f master 36785d7

2) openbios update repo (updated daily via cron):

    # update script contents
    # continue fetch svn commits for now as well
    # 'official' branch tracks github/master
    git svn fetch svn 
    git merge git-svn
    git fetch github   # official openbios github repo
    git push /pub/git/openbios.git master:svn-head
    git push /pub/git/openbios.git official:master  


Non-server side actions
======================

* QEMU new patch to switch over

    # normal submodule stuff:

    git submodule init
    git submodule update roms/openbios

    # create patch to switch over:
    cd roms/openbios
    git checkout master
    cd ../
    git commit -a  # assuming you made no other changes


* Existing users of git://git.qemu.org/openbios.git as a standalone work
  repo:

    git fetch

    # if there are local commits / work they want to keep
    git rebase origin/master
   
    # alternatively:
    git reset --hard origin/master                         



The above all seems to work in my testing.  Stefan, Mark: do you see any
glaring issues with the above?


-Jeff