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

[Mark Cave-Ayland]

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.


ATB,

Mark.