Request for a new vue3 branch in webui-vue

Gunnar M gunnar at gmills.xyz
Thu Jul 4 06:33:47 AEST 2024


> On 06/26/2024 7:06 PM MDT Andrew Jeffery <andrew at codeconstruct.com.au> wrote:
> 
>  
> On Wed, 2024-06-26 at 15:24 -0700, Ed Tanous wrote:
> > On Wed, Jun 26, 2024 at 3:10 PM Patrick Williams <patrick at stwcx.xyz> wrote:
> > > 
> > > On Wed, Jun 26, 2024 at 02:57:25PM -0700, Ed Tanous wrote:
> > > > On Wed, Jun 26, 2024 at 2:40 PM Patrick Williams <patrick at stwcx.xyz> wrote:
> > > > > 
> > > > > On Wed, Jun 26, 2024 at 02:46:29PM -0600, Gunnar M wrote:
> > > > > > Kiran and his team have volunteered to sync patches merged to master to this new 'vue3' branch bi-weekly. Thank you, Kiran! When the migration to Vue 3 is complete, and all commits are synced over, this 'vue3' branch will become the 'master' branch.
> > > > > 
> > > > > We need to be careful about how we do this.  You don't want it to appear
> > > > > on github as a rewrite of the "master" branch and we absolutely need to
> > > > > at least keep the vue2 code in some branch so that it doesn't get pruned
> > > > > from the github history.  If we don't do this, it will become impossible
> > > > > for people to build older OpenBMC releases.
> > > > > 
> > > > > I would suggest either:
> > > > > 
> > > > >     a. We do the opposite: create a 'vue2' branch and update the recipe
> > > > >        to point at it.
> > > > > 
> > > > >     b. We use this as an opportunity to migrate from 'master' to 'main'
> > > > >        and use 'main' as the vue3 branch.
> > > > 
> > > > 
> > > > My expectation was that this branch continues to rebase in patches,
> > > > and once ready to merge, we would just rebase the series on top of
> > > > master before pushing it so there's no discontinuity, no merge commit,
> > > > and autobump would just pick it up.
> > > 
> > > We would have to give "Kiran and his team" permissions in Gerrit to
> > > force-push to the "vue3" branch in order to facilitate these rebases.
> > 
> > Sorry, I should've said "My expectation was that this branch continues
> > to cherry-pick in patches"
> > 
> > There'd only be one rebase and push (not force I think?), right at the
> > end, 
> 
> You don't have to rebase either. Another option is to use `git merge -s
> ours` to join the branch histories but set the tree state in favour of
> one side.
> 

Does `git merge -s ours` work? And then go with a new `vue3` branch? 

If not, I am okay with using this as an opportunity to migrate from 'master' to 'main'. It is just a bit unexpected. If we go that route, we can add some temporary documentation.

I was thinking Kiran and team would cherry-pick patches merged to 'master' and push them to the 'vue3' branch, leaving the original author's signed-off, etc. I wasn't thinking any special permissions would be needed until "merging" the branches at the end. 

Thanks,
Gunnar


More information about the openbmc mailing list