Patches to Paper are very simple, but center around the directories 'LumiPaper-API' and 'LumiPaper-Server'
Assuming you already have forked the repository:
- Pull the latest changes from the main repository
- Type
./lumi patchin git bash to apply the changes from upstream - cd into
LumiPaper-Serverfor server changes, andLumiPaper-APIfor API changes
Adding patches to Paper is very simple:
- Modify
LumiPaper-Serverand/orLumiPaper-APIwith the appropriate changes - Type
git add .to add your changes - Run
git commitwith the desired patch message - Run
./lumi rebuildin the main directory to convert your commit into a new patch - PR your patches back to this repository
Your commit will be converted into a patch that you can then PR into Paper
By default, Paper (and upstream) only import files that we make changes to. If you would like to make changes to a file that isn't present in Paper-Server's source directory, you just need to add it to our import script to be ran during the patch process.
- Save (rebuild) any patches you are in the middle of working on!
- Identify the names of the files you want to import.
- A complete list of all possible file names can be found at
./work/Minecraft/$MCVER/net/minecraft/server
- A complete list of all possible file names can be found at
- Open the file at
./scripts/importmcdev.shand add the name of your file to the script. - Re-patch the server
./lumi patch - Edit away!
This change is temporary! DO NOT COMMIT CHANGES TO THIS FILE! Once you have made your changes to the new file, and rebuilt patches, you may undo your changes to importmcdev.sh
Any file modified in a patch file gets automatically imported, so you only need this temporarily to import it to create the first patch.
To undo your changes to the file, type git checkout scripts/importmcdev.sh
Using the lumi script, make sure to stash or commit all local changes first (and run lumi rb, lumi patch).
Follow this with lumi up up and lumi patch. If there aren't any merge conflicts, you're done - else, fix them ;)
In case you need something more complex or want more control, this step-by-step instruction does exactly what the above slightly automated system does.
- If you have changes you are working on type
git stashto store them for later.- Later you can type
git stash popto get them back.
- Later you can type
- Type
git rebase -i upstream/upstream- It should show something like this.
- Replace
pickwitheditfor the commit/patch you want to modify, and "save" the changes.- Only do this for one commit at a time.
- Make the changes you want to make to the patch.
- Type
git add .to add your changes. - Type
git commit --amendto commit.- MAKE SURE TO ADD
--amendor else a new patch will be created. - You can also modify the commit message here.
- MAKE SURE TO ADD
- Type
git rebase --continueto finish rebasing. - Type
./lumi rebuildin the main directory.- This will modify the appropriate patches based on your commits.
- PR your modifications back to this project.
If you are simply editing a more recent commit or your change is small, simply making the change at HEAD and then moving the commit after you have tested it may be easier.
This method has the benefit of being able to compile to test your change without messing with your API HEAD.
- Make your change while at HEAD
- Make a temporary commit. You don't need to make a message for this.
- Type
git rebase -i upstream/upstream, move (cut) your temporary commit and move it under the line of the patch you wish to modify. - Change the
pickwithf(fixup) ors(squash) if you need to edit the commit message - Type
./lumi rebuildin the main directory- This will modify the appropriate patches based on your commits
- PR your modifications to github