You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2018/10/09 18:07:19 UTC
Git struggles, basics
Hi,
I'm trying to use git in order to checkout the maven-gpg-plugin. Our spreadsheet
https://docs.google.com/spreadsheets/d/1k4XpPA0YFzOp2bDtkXXGbXEN4bdu4u-ummTdn8tvd_Q
on how to do things needs some updating - I'm currently stuck searching for
basic answers.
To check out the spreadsheet say to do a git clone <url>.
I don't know the url. What I have is this http link:
https://gitbox.apache.org/repos/asf?p=maven-gpg-plugin.git
I note that this is the same kind of link uimaFIT has.
That URL doesn't work in the git clone command.
============
The spreadsheet has an entry under ASF Conventions "Apache Home on GitHub".
This seems only partially true. For instance, the very thing I'm trying to do
is on "gitbox" not "github"?
Re: workflows in Eclipse: I have the Eclipse "egit" plugin installed, I think it's
the "standard" support. Is there a workflow for checking out a maven project
as a named branch, working on it, committing it (locally), and then making a
request to the project owners to pull your changes? I couldn't seem to find
how to do step 1 (e.g., check out a project as a new Eclipse project-branch).
Anyone know how to do that?
-Marshall (struggling...)
Re: Git struggles, basics
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 16. Oct 2018, at 22:49, Marshall Schor <ms...@schor.com> wrote:
>
> On github.com/apache, if you search for uima, you see hits apache/uima-uimaj and
> apache/uima-uimafit (and others).
> I guess pushing to apache/uima-uimafit would update gitbox.a.o, while it would
> not for uima-uimaj.
Yep. Only uima-uimafit is writable and syncs to gitbox.a.o.
The other uima projects are mirrored read-only at GitHub. Although people
could still fork them from there and create pull requests. But the pull
requests could not be merged via GitHub. They would have to be exported
as patches, attached to a Jira, and then be merged manually by a UIMA
committer.
In the uimaFIT project, I can automatically build PRs from contributors via
Apache Jenkins and I can conveniently review and merge them through the GitHub website
without having to go through the traditional routine of checking the
source out locally, patching it with the contribution, building locally, etc.
Although I mostly do this for myself at the moment since there are not (m)any
contributions at this time.
Cheers,
-- Richard
Re: Git struggles, basics
Posted by Marshall Schor <ms...@schor.com>.
excellent! That's what I concluded...
Here's what INFRA says:
The documentation is currently correct, though I get how it can be
misleading. Writable Git repos are hosted on git-wip-us (they have been
for a long time). Those are mirrored to git.a.o and github as read-
only. GitBox is a newer service that enables gitbox.a.o and github.com
as writable remotes. New projects are setup to use GitBox by default,
older projects still use git-wip.
We'll be updating all those docs in the future as we move to GitBox as
default (no ETA).
On github.com/apache, if you search for uima, you see hits apache/uima-uimaj and
apache/uima-uimafit (and others).
I guess pushing to apache/uima-uimafit would update gitbox.a.o, while it would
not for uima-uimaj.
Cheers. -Marshall
On 10/16/2018 3:48 PM, Richard Eckart de Castilho wrote:
> I asked INFRA a while back about this. What I understood from their answer is that:
>
> git-wip-us are Apache-hosted GIT repos that are *not* integrated with GitHub.
>
> gitbox essentially offers an integration of GitHub with the ASF infrastructure, i.e. mirroring of the GitHub repo on the ASF servers, sending commit notifications to the ASF project's mailing lists, hooking up with Jira, etc. That allows to make use of the social coding features from GitHub while meeting the provenance tracking requirements of the ASF.
>
> I believe that people adopting Git at ASF nowadays probably all use the gitbox approach.
>
> Cheers,
>
> -- Richard
>
>> On 16. Oct 2018, at 21:00, Marshall Schor <ms...@schor.com> 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
>
Re: Git struggles, basics
Posted by Richard Eckart de Castilho <re...@apache.org>.
I asked INFRA a while back about this. What I understood from their answer is that:
git-wip-us are Apache-hosted GIT repos that are *not* integrated with GitHub.
gitbox essentially offers an integration of GitHub with the ASF infrastructure, i.e. mirroring of the GitHub repo on the ASF servers, sending commit notifications to the ASF project's mailing lists, hooking up with Jira, etc. That allows to make use of the social coding features from GitHub while meeting the provenance tracking requirements of the ASF.
I believe that people adopting Git at ASF nowadays probably all use the gitbox approach.
Cheers,
-- Richard
> On 16. Oct 2018, at 21:00, Marshall Schor <ms...@schor.com> 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
Re: Git struggles, basics
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@schor.com> 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
>>>
>>>
>>>
Re: Git struggles, basics
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@schor.com> 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
>>
>>
>>
Re: Git struggles, basics
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 16. Oct 2018, at 20:03, Marshall Schor <ms...@schor.com> 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,
On a social coding site like GitHub, you normally fork only repos that you do
not have write permissions to. The purpose of the fork is that you create a
space where you can push your changes and offer them to others, usually via
a pull request.
If you are a maintainer of an open source project and already have write
permissions on your GitHub repo, there is no need to fork it.
> 2) on the local clone, make a branch
Aye
> 3) do changes, test etc., and commit to the branch
Aye
> 4) push the branch back to writable-Git spot (because we have committer permissions)
Aye - if you have commit permissions to the main project repo, you push your branch
directly to it. You could even not make a branch and simply push your changes to
master (or some other development branch). That would pretty much what you are used
to from SVN. But, I would recommend adopting the branching practice. Branching
is very cheap and easy in git and you'll only learn to value the branches after
making it a habit to create them.
> 5) ask the "owner" (or maybe pretend to be the owner) to "pull" the branch into
> the master, after they are satisfied.
If you are the sole developer: yes - you merge your own PRs (or as mentioned above,
you simply always commit to master)
If you are not the sole developer and you have a reasonably active project, you
might want to choose that every PR should be reviewed and approved before merging.
It is possible to set up GitHub in such a way that merges are not enabled unless
certain quality criteria have been met, e.g. unless Jenkins succeeds building the
PR, unless the PR branch is up-to-date with respect to the target branch (i.e.
no surprises after merge), or unless a configurable number of approvals have
been given. Of course, as a project owner, you can always merge.
> So in this case, there's no need to make a fork of the repo on the Apache
> writeable-Git spot, correct?
If you have write permissions to the project repo -> no need to fork.
> That was only needed if there were no permissions
> to push the new branch back into the original repo?
Exactly.
> ======
>
> 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.
I'd say that "GitHub website" in this case refers to "https://github.com/apache/maven-gpg-plugin"
You go there and press the "fork" button - since you do not have karma to commit to that repo.
The fork will be created as "https://github.com/mischor/maven-gpg-plugin".
> In other words, should we try to
> put forks for this purpose under the "apache" "section" of github? What's the
> right "protocol"?
You cannot create repos under "https://github.com/apache" - only INFRA can do that.
If you wanted to avoid creating a fork under your own account (https://github.com/mischor),
you'd have to ask the Apache PMC to which you want to contribute for committer permissions
so that you could push your branch there directly.
Cheers,
-- Richard
Re: Git struggles, basics
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@schor.com> 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
>
>
>
Re: Git struggles, basics
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 9. Oct 2018, at 21:45, Marshall Schor <ms...@schor.com> 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
Re: Git struggles, basics
Posted by Marshall Schor <ms...@schor.com>.
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
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.
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.
:-) Cheers. -Marshall
On 10/9/2018 4:26 PM, Richard Eckart de Castilho wrote:
> On 9. Oct 2018, at 19:38, Marshall Schor <ms...@schor.com> wrote:
>> Still confused.
>>
>> It appears I can do
>>
>> git clone https://gitbox.apache.org/repos/asf/maven-gpg-plugin.git OR
>>
>> git clone https://github.com/apache/maven-gpg-plugin
>>
>> Are these the same thing?
> Yes and no :)
>
> Yes: you'll end up with the same code in both cases because ASF GitBox syncs with GitHub
>
> No: in the first case the "remote" of your clone will be ASF gitbox and in the second case,
> the "remote" of your clone will be GitHub. In both cases, you could still add the other
> one as a second "remote" to your local clone. Both probably won't get you far if you
> want to contribute code because you likely have commit permissions to neither of the two
> repositories.
>
> Because of that you'd probably first want to go to the GitHub website, fork the "maven-gpg-plugin"
> repo under your own GitHub account, then clone *that*. If you have already cloned any of the
> others, you can could create the fork and add it as another remote to your local clone.
>
> Then, you create a branch, and commit your changes to that branch and push it to the
> forked repo under your GitHub account. Once the changes have been pushed there, you
> create a "pull request" via the GitHub website.
>
> Really, it sounds more complicated than it really is because there are so many ways
> that lead to more-or-less the same result, so I'll summarize the path of least resistance
> briefly:
>
> 1) fork repo on github
> 2) clone fork to your local pc
> 3) create branch
> 4) commit changes
> 5) push branch
> 6) create pull request
>
> Cheers,
>
> -- Richard
>
>
Re: Git struggles, basics
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 9. Oct 2018, at 19:38, Marshall Schor <ms...@schor.com> wrote:
>
> Still confused.
>
> It appears I can do
>
> git clone https://gitbox.apache.org/repos/asf/maven-gpg-plugin.git OR
>
> git clone https://github.com/apache/maven-gpg-plugin
>
> Are these the same thing?
Yes and no :)
Yes: you'll end up with the same code in both cases because ASF GitBox syncs with GitHub
No: in the first case the "remote" of your clone will be ASF gitbox and in the second case,
the "remote" of your clone will be GitHub. In both cases, you could still add the other
one as a second "remote" to your local clone. Both probably won't get you far if you
want to contribute code because you likely have commit permissions to neither of the two
repositories.
Because of that you'd probably first want to go to the GitHub website, fork the "maven-gpg-plugin"
repo under your own GitHub account, then clone *that*. If you have already cloned any of the
others, you can could create the fork and add it as another remote to your local clone.
Then, you create a branch, and commit your changes to that branch and push it to the
forked repo under your GitHub account. Once the changes have been pushed there, you
create a "pull request" via the GitHub website.
Really, it sounds more complicated than it really is because there are so many ways
that lead to more-or-less the same result, so I'll summarize the path of least resistance
briefly:
1) fork repo on github
2) clone fork to your local pc
3) create branch
4) commit changes
5) push branch
6) create pull request
Cheers,
-- Richard
Re: Git struggles, basics
Posted by Marshall Schor <ms...@schor.com>.
Still confused.
It appears I can do
git clone https://gitbox.apache.org/repos/asf/maven-gpg-plugin.git OR
git clone https://github.com/apache/maven-gpg-plugin
Are these the same thing?
-Marshall
On 10/9/2018 2:15 PM, Marshall Schor wrote:
> Ok, found this "guide": https://reference.apache.org/committer/git
>
> It says if your url is
> https://gitbox.apache.org/repos/asf?p=maven-gpg-plugin.git then use
> git clone https://gitbox.apache.org/repos/asf/maven-gpg-plugin.git
>
> That was step 1...
>
> -Marshall
>
>
> On 10/9/2018 2:07 PM, Marshall Schor wrote:
>> Hi,
>>
>> I'm trying to use git in order to checkout the maven-gpg-plugin. Our spreadsheet
>> https://docs.google.com/spreadsheets/d/1k4XpPA0YFzOp2bDtkXXGbXEN4bdu4u-ummTdn8tvd_Q
>> on how to do things needs some updating - I'm currently stuck searching for
>> basic answers.
>>
>> To check out the spreadsheet say to do a git clone <url>.
>>
>> I don't know the url. What I have is this http link:
>> https://gitbox.apache.org/repos/asf?p=maven-gpg-plugin.git
>>
>> I note that this is the same kind of link uimaFIT has.
>> That URL doesn't work in the git clone command.
>>
>> ============
>>
>> The spreadsheet has an entry under ASF Conventions "Apache Home on GitHub".
>> This seems only partially true. For instance, the very thing I'm trying to do
>> is on "gitbox" not "github"?
>>
>> Re: workflows in Eclipse: I have the Eclipse "egit" plugin installed, I think it's
>> the "standard" support. Is there a workflow for checking out a maven project
>> as a named branch, working on it, committing it (locally), and then making a
>> request to the project owners to pull your changes? I couldn't seem to find
>> how to do step 1 (e.g., check out a project as a new Eclipse project-branch).
>> Anyone know how to do that?
>>
>> -Marshall (struggling...)
>>
>>
Re: Git struggles, basics
Posted by Marshall Schor <ms...@schor.com>.
Ok, found this "guide": https://reference.apache.org/committer/git
It says if your url is
https://gitbox.apache.org/repos/asf?p=maven-gpg-plugin.git then use
git clone https://gitbox.apache.org/repos/asf/maven-gpg-plugin.git
That was step 1...
-Marshall
On 10/9/2018 2:07 PM, Marshall Schor wrote:
> Hi,
>
> I'm trying to use git in order to checkout the maven-gpg-plugin. Our spreadsheet
> https://docs.google.com/spreadsheets/d/1k4XpPA0YFzOp2bDtkXXGbXEN4bdu4u-ummTdn8tvd_Q
> on how to do things needs some updating - I'm currently stuck searching for
> basic answers.
>
> To check out the spreadsheet say to do a git clone <url>.
>
> I don't know the url. What I have is this http link:
> https://gitbox.apache.org/repos/asf?p=maven-gpg-plugin.git
>
> I note that this is the same kind of link uimaFIT has.
> That URL doesn't work in the git clone command.
>
> ============
>
> The spreadsheet has an entry under ASF Conventions "Apache Home on GitHub".
> This seems only partially true. For instance, the very thing I'm trying to do
> is on "gitbox" not "github"?
>
> Re: workflows in Eclipse: I have the Eclipse "egit" plugin installed, I think it's
> the "standard" support. Is there a workflow for checking out a maven project
> as a named branch, working on it, committing it (locally), and then making a
> request to the project owners to pull your changes? I couldn't seem to find
> how to do step 1 (e.g., check out a project as a new Eclipse project-branch).
> Anyone know how to do that?
>
> -Marshall (struggling...)
>
>