I found a Jira ticket requesting moving some project's GIT from git-wip-us to gitbox. I updated our google spreadsheet on git
https://docs.google.com/spreadsheets/d/1k4XpPA0YFzOp2bDtkXXGbXEN4bdu4u-ummTdn8tvd_Q/edit#gid=0 with a row describing this. I also wrote to infra users list pointing out that all the links you get to via googling, at the top, keep referring to what is probably the now old git-wip-us site; and also pointing out this conflicting instructions. -Marshall On 10/16/2018 3:00 PM, Marshall Schor wrote: > 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 >>> >>> >>>
