For working on our own projects, where we have "permissions", is it correct to think that
1) at the Apache writeable-Git spot, we go to the repo, and clone it to our local computer, 2) on the local clone, make a branch 3) do changes, test etc., and commit to the branch 4) push the branch back to writable-Git spot (because we have committer permissions) 5) ask the "owner" (or maybe pretend to be the owner) to "pull" the branch into the master, after they are satisfied. So in this case, there's no need to make a fork of the repo on the Apache writeable-Git spot, correct? That was only needed if there were no permissions to push the new branch back into the original repo? ====== In a previous reply, when you don't have permissions, it said: go to the GitHub website, fork the "maven-gpg-plugin"repo under your own GitHub account, then clone *that*. When this mentions "the GitHub website", does this refer to github.com/my-spots, or github.com/apache/some-new-repo-I-create. In other words, should we try to put forks for this purpose under the "apache" "section" of github? What's the right "protocol"? Cheers. -Marshall On 10/10/2018 4:58 AM, Richard Eckart de Castilho wrote: > On 9. Oct 2018, at 21:45, Marshall Schor <[email protected]> wrote: >> just curious, why doesn't this work: >> >> 1) clone project to local pc >> 2) create branch, make updates >> 3) commit changes >> 4) create a pull request for that commit > Because in step 3, you only commit to your local clone. > In order to create a pull request, the code needs to be > in a GitHub repo which is accessible by the receiving > party. So between 3 and 4, you'd have to push your branch > to such a repository. > >> Is it because with this approach, my pull request would somehow need to >> reference my clone on my local pc which others of course don't have access >> to? >> I kind of thought the pull request would "encapuslate" all the info it >> needed, >> sort of like a patch. > Imagine a pull request like a glorified issue which has special fields for > source and target branch. The PR is only metadata with pointers into > code repositories on GitHub. I does not actually contain changes itself. > >> For this particular case, what I did was: >> 1) clone project to local pc >> 2) create branch, make updates >> 3) make a "git"-style "patch" and attach the patch to the Jira. > That works, but of course you loose all the nice things about the > pull request such as: > > - ability to discuss the code line-by-line > - ability by the receiving party to check out your code as a branch and > collaborate with you (i.e. commit to your branch) > - continuous integration builds (if configured by the receiving party) > - ... > > Cheers, > > -- Richard > > >
