Refreshing v2 with changes from v1 using rebase

[Cervator]

With #19 merged we got a small slew of tweaks for the v1 release line. However, that yields a good illustration then of the challenge of maintaining both v1 and a v2 release lines 🤔

Doing double-checkins would suck, so I was curious to see how rebase would go at it and ... really easy, actually, partly thanks to Git Kraken. I use a similar approach with https://github.com/Nanoware/ModuleJteConfig where there's a single head commit that must not go to the MovingBlocks/ModuleJteConfig upstream, so I continuously rebase that one Nanoware-specific commit to the head and push to MovingBlocks from one commit older

Doing this with TeraNUI effectively gets us to the same place, just one meaningful commit is unique to the v2 line, the actual changes there from Benjamin. Then there are a couple release commits. The rebase even cleaned out a bunch of double-check-in commits from earlier. It looks mighty clean:

However, as noted in the header of this PR it isn't mergeable normally since it would require a force push, which would wipe out the original commit with the v2.0.0 tag corresponding to the original v2 release 🤔

So while this seems a seductively easy way to maintain the two release lines, it is also Evil ™️

Question is, with both @eviltak and @DarkWeird hovering around the topic of re-integrating latest Gestalt in Terasology, might the period during which we need to maintain a v1 and a v2 here be limited? Maybe that's hopeful thinking. But on the other hand I don't think DestSol would really care much for a while if its v2 of NUI can't be rebuilt exactly from its original tag, as long as the binaries are available and we can rebuild a newer snapshot post-rebase and validate that it would work with DS.

Decisions decisions. There's no rush to merge / address this right now, so leaving this marked WIP.

[Cervator]

Fun quirk: because of the rebase I think this won't build since a base + head here can't be made, explaining the "Expected" commit check that'll never arrive. At the same time since the latest commit already built in the past this PR inherited the checks from there 🤔 May have gotten the broken check from there instead, unsure.

[skaldarnar]

Hm, I think rebasing the main branche(s) regularly bears a lot of trouble as we are rewriting the history - and thus would change commits in the past ... As similar as v1 and v2 may seem, they technically are different releases, and they have diverging histories for a reason.
A part of the problem I see hear is that it's not clear what the main branch actually is - v2 (master) is newer, but I'm not even sure it's really used in DestSol yet(?). v1 is the legacy code line, but heavily used in the current state of Terasology. So, for most developers it would be natural to work on the legacy code, and then do an "upwards cherry-pick" to the main branch. This, eventually, leads to cherry picks going back and forth 🙈

I'd hope that, given our current pace, the double-maintenance is only a temporary thing, but it would nevertheless be valuable to learn how to do this properly 😅

[keturn]

closing in favor of #47