How to test for a feature before a pull request

Development
1

Hi , So i nearly solved this issue :

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

thanks .

2

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
3

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 ?

4

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.

Screenshot_2021-03-14_10-43-18
Screenshot_2021-03-14_10-43-181440×867 189 KB

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
5

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?

6

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 - jMonkeyEngine/jmonkeyengine: A complete 3-D game development suite written in Java.) 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
7

Yeh , thanks @Ali_RS :+1:.

8

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.

9

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

Then do a Git → Pull from IDE.

1 Like
10

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
11

My two cents, if you have other branches that, for whatever reason, you don’t want to lose, you can update your fork: Syncing a fork - GitHub Docs

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
12

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
13

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
14

Thank you all.

1 Like