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.