[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 1/1] OpenBIOS: Switch over to official OpenB
From: |
Jeff Cody |
Subject: |
Re: [Qemu-devel] [RFC PATCH 1/1] OpenBIOS: Switch over to official OpenBIOS git repo |
Date: |
Wed, 6 Jul 2016 23:12:23 -0400 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
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 <address@hidden> 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 <address@hidden>
> >>>>>>>>> ---
> >>>>>>>>> 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 <address@hidden>
> >>>>>>>
> >>>>>>> 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