For working with apache-writable git repos, there are two conflicting sets of instructions: https://git-wip-us.apache.org/ and https://reference.apache.org/committer/git
These say to use quite different URLs for cloning from, if you're a committer. e.g. (git-wip-us): git clone https://git-wip-us.apache.org/repos/asf/reponame.git (for committers) (git-wip-us): git clone http://git-wip-us.apache.org/repos/asf/reponame.git (for non-committers) (reference): git clone https://gitbox.apache.org/repos/asf/reponame.git (reference): git clone http://gitbox.apache.org/repos/asf/reponame.git What's the meaning of gitbox vs git-wi-us? I see uima-uimafit under the gitbox address, but not under the git-wip-us one. -Marshall On 10/16/2018 2:03 PM, Marshall Schor wrote: > 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 >> >> >>
