How to upmerge/rebase to master?

Creating Neos & Flow Code
1

Hi fellow Neos team members,

I would like to discuss how we want to handle upmerges in the future. Possibly this should result in a voting but I have no clever ideas yet.

I assumed already that existing PRs will be hard to update and that is true. I tried to somehow bring my PSR-7 change up to date, but it was pretty much impossible due to the way the Flow changes are counted by git. Even creating a patch file and adjusting the paths and stuff, didn’t really work out so far.

Therefore we need to brainstorm two things:

  1. Ways to get existing PRs up to master
  2. How to handle upmerging bugfixes in the future until the last version pre 4.0 is EOL

For the second robert suggested to just not upmerge and create two PRs for any lower branch bugfixes. We can probably not expect this from every contributor, so that means extra work compared to upmerging I guess. So unless we can come up with a reliable upmerge strategy, this will probably be the way to go.

2

I don’t see an other option, and agree that we can not enforce this double PR on every contributor. So for me it look like this will end up in the Github PR kitchen duty to produce a PR for Neos 3.0+ for every bugfixes, but it’s a lots of job … and will slow down us quiet a lots … :frowning:

About the current PR , at this point, no clue … need to brain storm a bit more and try/fail with some scripting, but not sure if we can provide a good/automate way to do that … the situation is quiet bad …

Just to braindump some ideas, currently git is “lost” because it think that we delete files and not rename them, so GIT is not able to do some work for us and both file are completly disconnected from the GIT point of view. Can this be solve in a way or an other … like reverting a lots of stuff, rewritte the namespace change commit and try to explain the really to GIT … just a brain dump …

3

I wondered the same… Maybe someone else has an idea that doesn’t necessarily involve redoing all the stuff.

4

Is it a github problem maybe? I think the file itselfs are flagged as renamed

5

The full Flow dev collection is not unfortunately.

6

Just brainstorming here and this might also create a lot of initial overhead:

So there is the GitHub API which also enables use to create Pull Requests.

What about a custom interface where people submit their bugfix PRs and a automated process applies migrations and create the same PR for master?

Or we could use this interface just internally to speed up the process for creating separate PRs for master

7

To put this into perspective it would be interesting to know roughly how many PRs we’re talking about.
Of course we have the challenge that we still have to support 2.3 (LTS) until August 2018 (plus security updates). I can imagine that this will be quite a lot of extra work during that time…

I like @dfeyer’s idea to try to re-commit the file moves, properly using git mv but I have no idea how much work that would be nor if it would really solve the problem during upmerge…

Another help might be a little script that takes a diff (the original PR) and adjusts it using search/replace so that we can (more) easily apply it to the 3.x branches

8

Hey there,

this is how the upmerge worked for me (tested with Flow):

git config merge.renamelimit 10000
git merge origin/3.3 -s recursive -X 'rename-threshold=1%'

:upside_down::upside_down::upside_down::upside_down:

All the best,
Sebastian

4 Likes
9

Can confirm, that worked nicely.

2 Likes