Collectible Card Game Headquarters

So, I finally made things work on my system. However I needed to locally change some files (playerview.java and all the pom.xmls) for that. Without these changes, Forge does not compile, or does not run/crashes with errors.
I couldn't and likely will never be able to find out where this incompatibility is coming from but it doesn't matter as long as I can make it work.

But here comes the problem.
I have this fix. If I commit this, everything works normal. But, the commit is pushed and then enters merge requests.
This stopped being a problem eventually for an unknown reason but today when I first updated my local master from core (to resolve some conflict) I figured out why.
The change, and its revert (which was only added to the remote) were already merged into core. Since already merged changes don't appear in a merge request, everything was working fine, and as the revert was also merged, it had no effect on core itself.

However, once I pulled from core, I now have the revert in my master and cannot run the game. So now I have to reapply and commit it, which will start to propagate the change into requests again. Which is bad.

So, question, how to keep this change locally (in ALL my branches, so don't suggest using it as a branch or patch, that's not reasonable when you work on dozens of branches) without it getting pushed and become part of merge requests. I tried looking around on the net but it pretty much says "git cannot do that" or suggests really complicated workarounds that do not help.

So how do I do this very basic and important operation in this system?

I don't have a good idea to fill your use case, but here specifically, it's really a symptom of your build not working with the "standard" version.

As I see it, your fix is to update Guava and use MoreObjects instead of Objects. I have searched a little, and the previously used API was removed in Guava 21, after it was deprecated in 2014. So I think your change really should be pushed to core after all. For some reason, you just were the first one to install a Guava>=21 when setting up their project.

I see the recent history of PlayerView.java as this:

Code: Select all

* [core/master] Merge branch 'multiplayer' into 'master'
|\
* | Continue but log NullPointerException in getMana
|/
| * [seravy/master] Fixes compile/run bugs in IntelliJ
|/
* Planchase Mod for mobile Forge. Uses BG art of current planes when a player planeswalk.
:


Unless I'm missing something, your change has not found its way into core, but when you tried to update your master you had a problem. The (to me) obvious solution is to merge your master, so that the situation is something like this:

Code: Select all

* [seravy/master] Merge Guava upgrade
|\
* | [core/master] Merge branch 'multiplayer' into 'master'
|\ \
* | | Continue but log NullPointerException in getMana
|/ /
| * Fixes compile/run bugs in IntelliJ
|/
* Planchase Mod for mobile Forge. Uses BG art of current planes when a player planeswalk.
:


Then, you can create a pull request (PR), which means that core/master can be updated with your changes, and once that's done your changes are in "official" forge and you shouldn't experience this problem any more.

https://git.cardforge.org/core-develope ... 89/commits

This is the one where my local file change, and its revert, got into the core. As both the change and the revert got in, at the same time from the same merge request, I assume the file itself never changed in core - but the commit and its revert does show up and comes down if I do a pull from core. As I never did a revert locally, the only possible way it could have entered my system was from core.

If this change was made "official" that would be the easiest solution but that's not for me to decide unfortunately.

I see... I actually fell into the trap you described when looking for the relevant commits; the merge didn't have the changes, so looking for commits that change the relevant files didn't work...

And you're sure you never created that revert commit yourself? 04809352, and 1cf40f45 from which it was cherry-picked, both indicate you as the author. In case you created the revert by mistake, I still think you should reapply that commit (i.e. cherry-pick it) and create a PR for the Guava upgrade. It's not for you to decide, yes, but that's why it's called a pull request: those in charge can choose to pull, or not. It seems logical to accept this PR, as the current Guava is over four years outdated.

If you're certain that you didn't create these commits, I'm at a loss what happened...

I created the revert on the website, so it was remote only.
Meaning it wasn't on my local master until after I got it through core.
Either way, you say I should submit a merge request for this change? I guess I can try that.

Ah! Well, git's job is to keep files in sync, so that remote change was bound to come back eventually.

Yes, I think that's the way to go. Basically, it's a bug fix - even though the bug is organizational (out-of-date dependency) rather than functional.