TODO: Make patching easier

[LexManos]

Posting this as a reminder to myself, and if anyone else wants to do it.
It would be really nice if we could make creation of patch files easier.
There are two approaches that would work:
Create a extra sourceset that all 3 sides {client/server/joined} share.
That sourceset would contain all files that are identical for all 3 sides. In 1.16.5, that's ~2000 of the ~3300 java files.
Which isn't a insignificant amount.

Option 2 is reversing the merge in the source files before generating the patches.
Theoretically, If we strip out everything @DistOnly and the imports for the markers we should have a source file identical to the stripped side. This is a complex process that would need a lot of testing.
However this is the best option for future dev, as we'd only have to fix the patches in one project.

Option 3 is we no longer ever need patches, but that requires FF to be a perfect decompiler. Which we're working on. But until this it'd be nice to get a better process.

[TheCurle]

So if i read this correctly:

Option A seems the easiest to create a quick solution for - add an extra psuedo-distribution called "shared" which contains files that are common between the client and server (and thus automatically joined, being the derivation of the combination of the two).

Then, the server and client distributions contain only the code relevant to the server and client, which helps pull some of the semantic confusion away as a bonus.

Whether this option is the best is up for debate, but it seems the quickest to make at a glance (should just be an extra block in the gradle buildscript and some handling in the Groovy files?)

It feels like this is somehow the same as option B - client + shared = the client stripped jar, and server + shared = the server stripped jar.

It occured to me while prototyping an improvement for MCPConfig that this would make mentally handling the patches significantly easier, but whether it would overall improve the handling in code is up for debate.

Option C.. well, we can only hope. It seems like most of the work that needs to go into ForgeFlower for now is to do with generic types, which is a rabbit hole and three quarters at this stage..

Well, rant over. Just wanted to write down my thoughts before they get lost to the ether.

[TheCurle]

So, we've done this.

We now have a shared sourceset additional to client and server, which deduplicates a lot of files.

However, our quest to make patching easier is not over!
Two new issues are incoming related to this.