Maintain fork using "negative diff" approach


#1

Maybe this could be a new topic, but I was wondering about the possibility of a “negative diff” kind of approach to keep ClassicPress up to date with WordPress updates…

That is, instead of a hard fork and having to review and add in every new change from WordPress, why not keep track of the differences that ClassicPress makes (which GitHub can do automatically anyway.)

So that when a new WordPress version comes out, any ClassicPress differences could be re-applied, and there could be some flag for those that don’t auto-apply (because the base WP code to be diffed has changed in the WP update.) I think given the size of the codebase, there would probably be fewer collisions that way, and it would be easier to keep track of the specifically chosen ClassicPress updates than all the WP ones.

I know there are pros and cons to each approach, but since ClassicPress is a fork of WordPress, to my mind it would make more sense to re-apply the changes on top of that base, rather than using ClassicPress as the base and trying to reinsert selectively from each new WordPress core version.

I hope that is clear enough, I’m not quite familiar with what the current process actually is, but this comes from thoughts of how I’d do such a fork. Mostly it just seems like a massive time burden to have to keep reviewing so many new tickets to keep up with changes, and something that will get harder over time and cause incompatibilities as things diverge… but it could be nipped in the bud with this alternative approach.


Backport WP5 trac tickets
#2

Note: I’ve moved this post to a new topic.

It definitely wouldn’t make sense for ClassicPress to be based on any WordPress 5.x branch, since the vast majority of the changes in 5.0 are things we don’t want.

Beyond that, ClassicPress could be thought of as based on the WordPress 4.9 branch. We’ve already made a large number of changes from that base, and the number of commits that we need to keep up with on the WP side is very small by comparison.

Keeping ClassicPress always based on the latest WP code would mean rewriting the ClassicPress commit history every time WordPress makes a change, which also doesn’t make much sense.

Regardless of what specifically goes where, git is a huge time saver here. You are describing some sort of system to manipulate and manage patch sets without duplicating work…this is exactly what git is, and it’s how we are already using it.

I still think we’ll need some tools on top of that to keep track of what changes we’ve already processed from WP, but really this isn’t something that’s giving us much trouble right now.


#3

Yes tracking changes more easily is kinda what I was getting at… not necessarily rebasing the fork off a 5+ branch, but rather, since the git repo exists for ClassicPress and WordPress, some kind of way to compare versions…which would make it clearer what has changed and what may need to be reviewed…

So if I can get my head around it a bit further, some kind of way to make comparison of the changes from WP4.9.8 to WP5.x with the changes from WP4.9.8 to CPx… comparing the forks from the 4.9.8 point,

But also yeah some way for devs to more easily mark old diffs and highlight new one would be handy? Even for end users to know so they can fix potential conflicts? I know there are some tools out there to do this manually, but not sure what an automated or semi-automated workflow for this would look like?


#4

git log and git diff can do everything you are describing here as far as comparisons.

git cherry-pick can apply any combination of changes we want to look at, only prompting to resolve any conflicts which should be minimal. This is how we’ve kept ClassicPress up to date with the WP 4.9 branch so far.

What’s still left to do is a way to track which changes we’ve accepted or rejected from other branches like 5.0, and link “merged” WP changesets together. This is what the web app described on the other thread will do. Until that’s ready we will mostly just keep up with the 4.9 branch which is easy.