How to test for a feature before a pull request

Hi , So i nearly solved this issue :

but i need to test my work before submitting a pull request , are there any ideas ?

thanks .

Hmmm… not sure… maybe create a test scene (can be a simple box with a texture) and run it on both desktop and android with and without gamma correction checked and take a scene screenshot and compare them!

1 Like

Yep thanks , so I was wondering too , how can I test my change in code , since I will change in a code that is used by android-native so I cannot do this without re-uploading the whole engine or the whole android & android-native to gradle again on my own ? I need to test the engine as if my pull request has been reviewed & submitted . Hope you are getting it ?

Ah, I see now.

I would suggest cloning the engine locally from the master branch then make the changes and run the gradle install task on the modified module. It will build and add the 3.4.0-SNAPSHOT jar into the local maven repository so you can easily use it in your project.

Then in your test android project build.gradle you just need to change JME version to 3.4.0-SNAPSHOT.

for example

implementation "org.jmonkeyengine:jme3-desktop:3.4.0-SNAPSHOT"

also make sure you have added mavenLocal() to the repositories.

repositories {
   
    //Uncomment this if you install local dependencies.
    mavenLocal()
}
2 Likes

Oh thanks , I have cloned the repo yesterday , but was really thinking hard how could I manage this :slightly_smiling_face::grin:.

BTW , should I do rebase before merging/the pull request?

I have never used rebase before so I do not know!!

Also I think you should clone the JME from your fork (Not from github.com/jMonkeyEngine/jmonkeyengine) and then you can directly commit the changes to your fork of JME on Github using git push, then from Github website you can create and submit the PR.

1 Like

Yeh , thanks @Ali_RS :+1:.

Well , I have an old fork , but it’s 82 commits behind , so what now ?

Guidelines should be updated to include sort of these stuffs.

Okay. I have created new organization & forked into , when I want to rebase with jme , I will just change the remote , rebase , then switch it back to my organization.

Well in my case I just delete it and re-fork it :grinning:

Then do a Git → Pull from IDE.

1 Like

If anyone thinks what I am writing is not correct, say so.

Before merging your changes onto your local master from your working branch, you should update you local master, which means your fork needs to be up to date to do so.

I find it’s easier/safer to first delete the fork, re-fork jmonkey again and then do a pull to your local master.

When you change back to your working branch from your local master after the pull, you will be asked if you want to merge the changes into your working branch.

There shouldn’t be a conflict as it sounds like you are working on different things than most but if there is you have to resolve the conflicts.

Once done with that, you then merge your changes into your local master, push to your github fork, and issue a clean pr to jmonkey.

2 Likes

My two cents, if you have other branches that, for whatever reason, you don’t want to lose, you can update your fork: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork

If you don’t feel like messing with command line you can do it from the github website as follows:

  • Go to your fork page and click “Pull request”
  • On the left side select your fork and on the right side select the upstream (jMonkeyEngine/jmonkeyengine in your case)
  • Create the PR and then accept it
1 Like

You shouldn’t need to worry about your fork’s main branch being up to date, and constantly deleting and re-cloning the engine is a major waste of computer time (and yours). Here’s a simple way to keep up to date while doing independent dev work on the engine:

  • On your local repo (the one that lives on your computer) have a single main branch that is set up to track the engine repo’s main branch. The Only thing that you use this branch for is to get the latest updates from the JME project.
  • Each time you want to start working on a bug or engine feature:
    • Switch to that main branch
    • git pull to get the latest updates from the engine
    • git checkout -b <branchname> to create a new branch to do your work in
  • When your work is ready for a PR, git push -u <yourfork> <branchname> to put your changes on github. If you need to make changes to this branch later, just use git push.
  • Use the github UI to actually generate a Pull Request
  • Once the PR is merged, it is safe to delete <branchname> from both your local repo, and your github fork.
2 Likes

Theres a difference between using the web interface and git command line. For simplicity, we suggested the web interface since learning git command line would take more effort.

With the web interface, it is best to delete and re-fork (using the web interface to do so only takes seconds and you don’t have to re-clone). Your fork history will get polluted after just one merge using the web interface. There is a github action you can use in conjunction with the web interface to keep your fork in sync but it comes with its own issues.

Git command line and push to fork is by far the best approach though if you know it.

Edit: You can use a GUI to do what @sailsman63 described also.

1 Like

Thank you all.

1 Like