Support unobfuscated versions

[0x189D7997]

Adds support for the new 'unobfuscated' experimental snapshots.

Closes #35.
Credit to @davepusey for initial work and helpful ideas on this.

[davepusey]

Yarn and intermediary are not required for the unobfuscated versions. You need to use --fallback-mappings=identity_unmapped when running.

[0x189D7997]

Yarn and intermediary are not required for the unobfuscated versions. You need to use --fallback-mappings=identity_unmapped when running.

Yes, they don't exist and will not. This needs to be handled properly when Yarn is used for fallback to work or to skip unobf versions (in case a user includes them with versions that do have Yarn). This is what I did in these commits.

I have tested this and everything seems to work fine except for --create-version-branches. Only one branch is created while there should be branches for both snapshots. Needs to be fixed by changing logic when processing parallel branches in pipeline.workers.Committer and that option is used.

[0x189D7997]

except for --create-version-branches. Only one branch is created while there should be branches for both snapshots.

Turns out this issue in not unique to unobf. snapshots. I will be fixing it in #31.

[SpaceWalkerRS]

imo yes - and this is for a separate PR but since 0.17 Loader has much improved version normalization so the overrides could do with some cleaning up

[0x189D7997]

imo yes - and this is for a separate PR

Actually I found out some more dependencies can be updated without (at least from brief testing) breaking anything.
I'm not sure which ones should be updated, you can see all the (latest as of now) versions here:
master...0x189D7997:GitCraft:update
Can probably combine that and removing old overrides in an update PR.

[4lve]

Does this mess up version history or is there any way to only include unobfuscated versions?

[0x189D7997]

Does this mess up version history

No, they get committed to a separate branch.

is there any way to only include unobfuscated versions?

Currently only by selecting them manually with --only-version=25w45a_unobfuscated,25w46a_unobfuscated...
I can add a toggle specifically for them if that is agreed on.

If you want to exclude them I'd suggest using --skip-nonlinear as of now.

[WinPlay02]

I can add a toggle specifically for them if that is agreed on.

I also want to add a new mappings option called mojmap_unobfuscated which acts as mojmap for regular versions and as identity_unmapped for unobf ones. Use it as the default so future versions do not need the fallback workaround. Or maybe make mojmap behave like this, and rename its current implementation to mojmap_strict?

@WinPlay02 do you think this is a good idea?

I absolutely agree on this idea, I like the mojmap / mojmap_strict separation slightly better. Although this changes the default behavior somewhat (I'd say versions that have mojmaps and unobfuscated jars should prefer the unobfuscated jars), it would be pretty much what is expected when running this tool.

[0x189D7997]

Please don't merge this yet, I might add some tests later.

I'd say versions that have mojmaps and unobfuscated jars should prefer the unobfuscated jars

They are experimental (and also technically have different names) so I think mods are not likely to target them, and we should follow this trend and only prefer them after they become the standard (that is starting with 26.1 snapshots).

[0x189D7997]

The CI fail as follows:
assertEquals("26.1-snapshot-1", vgNonObfuscated.filterMainlineVersions().getMainRootVersion().launcherFriendlyVersionName())
Expected: 26.1-snapshot-1
Actual: 25w45a_unobfuscated

This exposes a flaw in MinecraftVersionGraph.filterMainlineVersions() which under some circumstances will not, in fact, filter out some non-mainline versions. I have already fixed this as part of a MinecraftVersionGraph's branch logic rewrite I have yet to publish as a PR.
If needed I can create a separate PR with only this change.

[0x189D7997]

@WinPlay02 @4lve Besides the unrelated issue above this should be ready. All previously discussed features are added.

[WinPlay02]

Thanks for implementing this (also to @davepusey for their contributions)