I’ve already jumped in the Github pool with my projects, though they’ve pretty much been just me.
That’s just fine. My stuff doesn’t have to be popular or anything like that.
My request is for someone already in the Github pool… or Git… IDK…
Would someone please fork this project:
add some type of picture here:
it would be:
src/org/jme3/netbeans/plaf/darkmonkey/icons
if viewing it from Netbeans.
and then send a pull request? I’ll make sure to say “Hi n stuff”
I’ve just now figured out how to do a pull request for jMonkeyEngine (now I can also help out if I figure out how to do something cool) Thank you for the help on that @Momoko_Fan.
Now I just need to figure out how to manage pull requests, so that I don’t have to worry about inadvertently nuking my project… So, if anyone has the time, go for it!
I usually setup different pull and push repository paths if i only work on a fork.
As for jme, “pull” pulls the changes from the Jme/Master and “push” pushes the changes to my fork.
That works good (without manual management) until the point you allow pull requests to your own fork too.
At least thats a workflow i am used to, and up to now it always worked for me
I think I did what @Empire_Phoenix described, though I might try yours later on, if I get confident enough. It sounds like a “buffered” type of situation that allows you to work on your own fork… and be able to have a pure fork to view others stuff? … is that about right?
I also got to see @nehon doing a “push”… onto a pull request? and then uploading the… pushed… pull? So… I’m guessing that a normal commit is technically a push, … but it’s called a commit on the button. So, I think I have corrected internal definition for commit from “commit” to “committed push” ← Correct me if I’m wrong. And “pull requests” are “commits without authority to do so”, or a request for someone to “push” your product for you. And a “push”… though all commits might be considered pushes in Git… in Github, the term might mean… “an edit pushed upon someone’s pull request” is this the fabled “pushmi-pullyu” from Dr. Dolittle? or is it a better applied concept?:
That would be awesome! Though, I usually get ahold of some “evolved concept”, and end up in situations like this… (watch Futurama’s “Attack of the Killer App” episode to get the full setup involving the evolved Mr. Chunks - The Infosphere, the Futurama Wiki):
ahh… yeah… :chimpanzee_facepalm:
Anyways, I think I have everything clear, atm. Make sure to give me a heads up if I am wrong on my conception of the normal usage of “commit”, “pull request”, and “push”… It seems to make sense to me to see it in action.
Yeah i did that yesterday. Was more an experiment. I pulled a PR locally, to test it. Find out that there were missing things,. I did them then I committed and pushed the change to the “PR”.
The thing is…it didn’t really pushed to the PR itself, it created a branch from the PR and pushed to that branch.
Then, I had the option to make a PR from this branch that I merged to core.
Then it went a bit mad…because my local pr branch was messed up because it was somehow pointing to the newly created branch and the PR…so in the end I deleted the remote branches and all worked again…
I doubt I’ll try that again.
I think you don’t get how it really works.
your local repo is autonomous really and the remote repo is just the synchronisation and integration of the different repos of the contributors.
For example, someone could decide that his remote repository is your local repo. That’s how git works (idk if it’s used a lot that way though).
There are 3 stages for a file that is your local git repo.
A file you modified is unstaged by default, meaning that you
modified it in your local copy.
You can add it to the staging
area. The file is now staged, meaning that this file is admissible
for the upcoming commit.
You can now commit the file, meaning git will create a commit with the changes you did to the file in your local git repo. Note that you can makes as many commits as you want without ever making a push. As said your local repo is autonomous and you could have a local version control.
At some point you want to send your commits to the remote repository so that everyone can have them, that’s the push operation.
