Request for a new vue3 branch in webui-vue

Andrew Jeffery andrew at codeconstruct.com.au
Thu Jun 27 11:06:57 AEST 2024


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.

I have been doing this with our qemu fork:

https://amboar.github.io/notes/2021/09/16/history-preserving-fork-maintenance-with-git.html

Andrew


More information about the openbmc mailing list