You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Jukka Zitting <ju...@gmail.com> on 2009/05/03 13:20:11 UTC
Moving Git instructions to www.apache.org
Hi,
I'm about to start migrating some of the Git instructions we currently
have on the wiki to a more "official" location on the www.apache.org
web site.
See below for my first shot at the content I'm about to publish at
http://www.apache.org/dev/git.html. As a new part I'm including a
section with a proposed workflow for contributors that use Git. The
instructions for the committer workflow IMHO still need some work so
for now I was thinking of leaving them on the wiki.
Once I have this page published, I'll be posting an entry on the Infra
blog about the Git mirrors we have.
BR,
Jukka Zitting
<?xml version="1.0"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<document>
<properties>
<title>Git access to Apache codebases</title>
</properties>
<body>
<section>
<title>Git access to Apache codebases</title>
<p>
The Apache Software Foundation uses
<a href="http://subversion.tigris.org/">Subversion</a> as the main
<a href="version-control.html">version control</a> infrastructure,
but we also provide some level of support to users of the
<a href="http://git-scm.com/">Git</a> version control system.
This page describes how you can use Git with Apache codebases.
</p>
<toc/>
<section id="git-mirrors">
<title>Git mirrors</title>
<p>
We maintain read-only Git mirrors of many Apache codebases at
<a href="http://git.apache.org/">http://git.apache.org/</a>.
These mirrors contain the full version histories (including all
branches and tags) of the mirrored codebases and are updated in
near real time based on the latest svn commits.
</p>
<p>
The mirrors can be cloned or pulled from using got the Git and
HTTP protocols. See the mirror page for the available clone URLs.
</p>
<p>
Please file an
<a href="https://issues.apache.org/jira/browse/INFRA">INFRA</a>
issue (component: Git) to request a new codebase to be mirrored
or to change the settings of an existing mirror. When requesting
a new mirror, please include the following information:
</p>
<ul>
<li>
Name of the codebase, for example "Apache Tika"
</li>
<li>
Name of the requested Git mirror, for example "tika.git"
</li>
<li>
Subversion path of the codebase, for example "/lucene/tika/"
</li>
<li>
Subversion layout, in case it is different from the standard
"trunk, branches, tags" structure.
</li>
</ul>
</section>
<section id="workflow">
<title>Proposed workflow</title>
<p>
This is a proposed workflow for using Git with an Apache codebase.
This workflow is mainly targeted to contributors who don't already
have commit access to a project.
</p>
<p>
Once you have cloned or pulled the latest changes to your local
Git repository of an Apache codebase, you can start working on it.
Whenever you make some changes to the codebase, it's good to have
a related issue filed in the issue tracker of the project and to
use a similarly named branch in your Git repository. For example,
to create a branch for an issue with the key TIKA-123.
</p>
<pre>git branch TIKA-123 origin/trunk</pre>
<p>
With per-issue branches you can easily switch back and forth between
different issues without worrying about unwanted side-effects from
unfinished changes to other issues. Whenever you want to work on
the TIKA-123 example issue, simply checkout that branch and start
making your changes.
</p>
<pre>git checkout TIKA-123</pre>
<p>
It's a good idea to commit your changes whenever you have finished
one logical part of the issue. For example when refactoring, make
a new commit for each refactoring step you take.
</p>
<pre>git commit</pre>
<p>
Once you're ready to share your changes with the rest of the project
team, you can use the git format-patch command to produce a nice
set of patches to attach to the relevant issue.
</p>
<pre>git format-patch origin/trunk</pre>
<p>
The sooner you share your work the better. You can repeat the
steps of this workflow as often as you like, producing more patches
to be attached to the issue tracker. Once some of your patches are
accepted and committed to svn, you can rebase your work against the
latest trunk. Alternatively, if you're asked to make some changes,
you can go back to the original Git commit and modify it until the
project team accepts your changes.
</p>
</section>
<section id="improvements">
<title>Ongoing improvements</title>
<p>
Improvements to Git support at Apache are being discussed on the
<a href="infra-mail.html">infrastructure-dev@ mailing list</a>.
This list is open to everyone and is
<a href="http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/"
>publicly archived</a>. You can subscribe this mailing list by
sending a message to
<a href="mailto:infrastructure-dev-subscribe@apache.org?subject=subscribe"
>infrastructure-dev-subscribe@apache.org</a>.
</p>
</section>
</section>
</body>
</document>
Re: Moving Git instructions to www.apache.org
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Jukka Zitting pisze:
> Hi,
>
> On Sun, May 3, 2009 at 4:10 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>> The only thing I would comment on here is that it would be far better to
>> create a workflow that harnessed the power of git so that we don't have to
>> make patches.
>
> Agreed, but that depends on committers who are capable and willing to
> deal with Git pull requests.
>
> It would probably be best to start with example projects where we
> could experiment things and come up with such recommended workflows,
> potentially supported by tools like Gerrit.
I agree with Jukka on this.
Proposed workflow is the one that does not impose using Git on other committers in order to review the changes. If we
find a project where all committers agree to have deeper integration with Git then we can experiment with Gerrit or
similar tool.
I'll be highly interested in supporting such a project.
Anything else looks good. Thanks you again for your continuous good work on Git-related stuff.
--
Best regards,
Grzegorz Kossakowski
Re: Moving Git instructions to www.apache.org
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, May 3, 2009 at 4:10 PM, Jason van Zyl <jv...@sonatype.com> wrote:
> The only thing I would comment on here is that it would be far better to
> create a workflow that harnessed the power of git so that we don't have to
> make patches.
Agreed, but that depends on committers who are capable and willing to
deal with Git pull requests.
It would probably be best to start with example projects where we
could experiment things and come up with such recommended workflows,
potentially supported by tools like Gerrit.
BR,
Jukka Zitting
Re: Moving Git instructions to www.apache.org
Posted by Jason van Zyl <jv...@sonatype.com>.
The only thing I would comment on here is that it would be far better
to create a workflow that harnessed the power of git so that we don't
have to make patches. If a group agrees that a GIT repo is tied to SVN
and you allow the community to pull from that and you have Gerrit
wired into the workflow then there is a complete history of submission
with CLA tracking and then we don't have to process patches. It is
extremely easy to do code review on submissions, make comments, push
it back to the contributor for further changes, perform further review
and ultimately pull into a repository and merged with SVN.
On 3-May-09, at 4:20 AM, Jukka Zitting wrote:
> Hi,
>
> I'm about to start migrating some of the Git instructions we currently
> have on the wiki to a more "official" location on the www.apache.org
> web site.
>
> See below for my first shot at the content I'm about to publish at
> http://www.apache.org/dev/git.html. As a new part I'm including a
> section with a proposed workflow for contributors that use Git. The
> instructions for the committer workflow IMHO still need some work so
> for now I was thinking of leaving them on the wiki.
>
> Once I have this page published, I'll be posting an entry on the Infra
> blog about the Git mirrors we have.
>
> BR,
>
> Jukka Zitting
>
>
> <?xml version="1.0"?>
> <!--
> Licensed to the Apache Software Foundation (ASF) under one
> or more contributor license agreements. See the NOTICE file
> distributed with this work for additional information
> regarding copyright ownership. The ASF licenses this file
> to you under the Apache License, Version 2.0 (the
> "License"); you may not use this file except in compliance
> with the License. You may obtain a copy of the License at
>
> http://www.apache.org/licenses/LICENSE-2.0
>
> Unless required by applicable law or agreed to in writing,
> software distributed under the License is distributed on an
> "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> KIND, either express or implied. See the License for the
> specific language governing permissions and limitations
> under the License.
> -->
> <document>
> <properties>
> <title>Git access to Apache codebases</title>
> </properties>
> <body>
> <section>
> <title>Git access to Apache codebases</title>
> <p>
> The Apache Software Foundation uses
> <a href="http://subversion.tigris.org/">Subversion</a> as the
> main
> <a href="version-control.html">version control</a>
> infrastructure,
> but we also provide some level of support to users of the
> <a href="http://git-scm.com/">Git</a> version control system.
> This page describes how you can use Git with Apache codebases.
> </p>
>
> <toc/>
>
> <section id="git-mirrors">
> <title>Git mirrors</title>
> <p>
> We maintain read-only Git mirrors of many Apache codebases at
> <a href="http://git.apache.org/">http://git.apache.org/</a>.
> These mirrors contain the full version histories (including
> all
> branches and tags) of the mirrored codebases and are
> updated in
> near real time based on the latest svn commits.
> </p>
> <p>
> The mirrors can be cloned or pulled from using got the Git
> and
> HTTP protocols. See the mirror page for the available clone
> URLs.
> </p>
> <p>
> Please file an
> <a href="https://issues.apache.org/jira/browse/
> INFRA">INFRA</a>
> issue (component: Git) to request a new codebase to be
> mirrored
> or to change the settings of an existing mirror. When
> requesting
> a new mirror, please include the following information:
> </p>
> <ul>
> <li>
> Name of the codebase, for example "Apache Tika"
> </li>
> <li>
> Name of the requested Git mirror, for example "tika.git"
> </li>
> <li>
> Subversion path of the codebase, for example "/lucene/
> tika/"
> </li>
> <li>
> Subversion layout, in case it is different from the
> standard
> "trunk, branches, tags" structure.
> </li>
> </ul>
> </section>
>
> <section id="workflow">
> <title>Proposed workflow</title>
> <p>
> This is a proposed workflow for using Git with an Apache
> codebase.
> This workflow is mainly targeted to contributors who don't
> already
> have commit access to a project.
> </p>
> <p>
> Once you have cloned or pulled the latest changes to your
> local
> Git repository of an Apache codebase, you can start working
> on it.
> Whenever you make some changes to the codebase, it's good
> to have
> a related issue filed in the issue tracker of the project
> and to
> use a similarly named branch in your Git repository. For
> example,
> to create a branch for an issue with the key TIKA-123.
> </p>
> <pre>git branch TIKA-123 origin/trunk</pre>
> <p>
> With per-issue branches you can easily switch back and
> forth between
> different issues without worrying about unwanted side-
> effects from
> unfinished changes to other issues. Whenever you want to
> work on
> the TIKA-123 example issue, simply checkout that branch and
> start
> making your changes.
> </p>
> <pre>git checkout TIKA-123</pre>
> <p>
> It's a good idea to commit your changes whenever you have
> finished
> one logical part of the issue. For example when
> refactoring, make
> a new commit for each refactoring step you take.
> </p>
> <pre>git commit</pre>
> <p>
> Once you're ready to share your changes with the rest of
> the project
> team, you can use the git format-patch command to produce a
> nice
> set of patches to attach to the relevant issue.
> </p>
> <pre>git format-patch origin/trunk</pre>
> <p>
> The sooner you share your work the better. You can repeat the
> steps of this workflow as often as you like, producing more
> patches
> to be attached to the issue tracker. Once some of your
> patches are
> accepted and committed to svn, you can rebase your work
> against the
> latest trunk. Alternatively, if you're asked to make some
> changes,
> you can go back to the original Git commit and modify it
> until the
> project team accepts your changes.
> </p>
> </section>
>
> <section id="improvements">
> <title>Ongoing improvements</title>
> <p>
> Improvements to Git support at Apache are being discussed
> on the
> <a href="infra-mail.html">infrastructure-dev@ mailing list</
> a>.
> This list is open to everyone and is
> <a href="http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/
> "
>> publicly archived</a>. You can subscribe this mailing list by
> sending a message to
> <a href="mailto:infrastructure-dev-subscribe@apache.org?subject=subscribe
> "
>> infrastructure-dev-subscribe@apache.org</a>.
> </p>
> </section>
>
> </section>
> </body>
> </document>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Moving Git instructions to www.apache.org
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Jukka Zitting pisze:
> Hi,
>
> On Sun, May 3, 2009 at 4:03 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>> Have you looked at Gerrit? The Mondrian replacement for code review that the
>> Android team is using as part workflow for fielding all contributions to
>> Android?
>
> Yeah, Gerrit looks pretty nice and covers many of the issues that
> people have been worrying about with Git.
>
> It would be interesting to start experiment with something like that.
FYI: I'll be working at Google on Gerrit-related project over summer as Google Intern. Can't say anything more at this
stage.
Anyway, it's very likely I'll have a serious influence on what I'll be working on so anything we miss in Gerrit might be
implemented rather soon. I'm waiting for suggestions. 8-)
This is one of the reasons why I was so slow at responding to infra tasks.
--
Best regards,
Grzegorz Kossakowski
Re: Moving Git instructions to www.apache.org
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, May 3, 2009 at 4:03 PM, Jason van Zyl <jv...@sonatype.com> wrote:
> Have you looked at Gerrit? The Mondrian replacement for code review that the
> Android team is using as part workflow for fielding all contributions to
> Android?
Yeah, Gerrit looks pretty nice and covers many of the issues that
people have been worrying about with Git.
It would be interesting to start experiment with something like that.
BR,
Jukka Zitting
Re: Moving Git instructions to www.apache.org
Posted by Jason van Zyl <jv...@sonatype.com>.
Have you looked at Gerrit? The Mondrian replacement for code review
that the Android team is using as part workflow for fielding all
contributions to Android?
It has built in support for CLA tracking where someone cannot submit
anything for review until they have a CLA on file. This process has
been vetted by Google legal for Android so it's something I'm sure
would be suitable for us.
On 3-May-09, at 4:20 AM, Jukka Zitting wrote:
> Hi,
>
> I'm about to start migrating some of the Git instructions we currently
> have on the wiki to a more "official" location on the www.apache.org
> web site.
>
> See below for my first shot at the content I'm about to publish at
> http://www.apache.org/dev/git.html. As a new part I'm including a
> section with a proposed workflow for contributors that use Git. The
> instructions for the committer workflow IMHO still need some work so
> for now I was thinking of leaving them on the wiki.
>
> Once I have this page published, I'll be posting an entry on the Infra
> blog about the Git mirrors we have.
>
> BR,
>
> Jukka Zitting
>
>
> <?xml version="1.0"?>
> <!--
> Licensed to the Apache Software Foundation (ASF) under one
> or more contributor license agreements. See the NOTICE file
> distributed with this work for additional information
> regarding copyright ownership. The ASF licenses this file
> to you under the Apache License, Version 2.0 (the
> "License"); you may not use this file except in compliance
> with the License. You may obtain a copy of the License at
>
> http://www.apache.org/licenses/LICENSE-2.0
>
> Unless required by applicable law or agreed to in writing,
> software distributed under the License is distributed on an
> "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> KIND, either express or implied. See the License for the
> specific language governing permissions and limitations
> under the License.
> -->
> <document>
> <properties>
> <title>Git access to Apache codebases</title>
> </properties>
> <body>
> <section>
> <title>Git access to Apache codebases</title>
> <p>
> The Apache Software Foundation uses
> <a href="http://subversion.tigris.org/">Subversion</a> as the
> main
> <a href="version-control.html">version control</a>
> infrastructure,
> but we also provide some level of support to users of the
> <a href="http://git-scm.com/">Git</a> version control system.
> This page describes how you can use Git with Apache codebases.
> </p>
>
> <toc/>
>
> <section id="git-mirrors">
> <title>Git mirrors</title>
> <p>
> We maintain read-only Git mirrors of many Apache codebases at
> <a href="http://git.apache.org/">http://git.apache.org/</a>.
> These mirrors contain the full version histories (including
> all
> branches and tags) of the mirrored codebases and are
> updated in
> near real time based on the latest svn commits.
> </p>
> <p>
> The mirrors can be cloned or pulled from using got the Git
> and
> HTTP protocols. See the mirror page for the available clone
> URLs.
> </p>
> <p>
> Please file an
> <a href="https://issues.apache.org/jira/browse/
> INFRA">INFRA</a>
> issue (component: Git) to request a new codebase to be
> mirrored
> or to change the settings of an existing mirror. When
> requesting
> a new mirror, please include the following information:
> </p>
> <ul>
> <li>
> Name of the codebase, for example "Apache Tika"
> </li>
> <li>
> Name of the requested Git mirror, for example "tika.git"
> </li>
> <li>
> Subversion path of the codebase, for example "/lucene/
> tika/"
> </li>
> <li>
> Subversion layout, in case it is different from the
> standard
> "trunk, branches, tags" structure.
> </li>
> </ul>
> </section>
>
> <section id="workflow">
> <title>Proposed workflow</title>
> <p>
> This is a proposed workflow for using Git with an Apache
> codebase.
> This workflow is mainly targeted to contributors who don't
> already
> have commit access to a project.
> </p>
> <p>
> Once you have cloned or pulled the latest changes to your
> local
> Git repository of an Apache codebase, you can start working
> on it.
> Whenever you make some changes to the codebase, it's good
> to have
> a related issue filed in the issue tracker of the project
> and to
> use a similarly named branch in your Git repository. For
> example,
> to create a branch for an issue with the key TIKA-123.
> </p>
> <pre>git branch TIKA-123 origin/trunk</pre>
> <p>
> With per-issue branches you can easily switch back and
> forth between
> different issues without worrying about unwanted side-
> effects from
> unfinished changes to other issues. Whenever you want to
> work on
> the TIKA-123 example issue, simply checkout that branch and
> start
> making your changes.
> </p>
> <pre>git checkout TIKA-123</pre>
> <p>
> It's a good idea to commit your changes whenever you have
> finished
> one logical part of the issue. For example when
> refactoring, make
> a new commit for each refactoring step you take.
> </p>
> <pre>git commit</pre>
> <p>
> Once you're ready to share your changes with the rest of
> the project
> team, you can use the git format-patch command to produce a
> nice
> set of patches to attach to the relevant issue.
> </p>
> <pre>git format-patch origin/trunk</pre>
> <p>
> The sooner you share your work the better. You can repeat the
> steps of this workflow as often as you like, producing more
> patches
> to be attached to the issue tracker. Once some of your
> patches are
> accepted and committed to svn, you can rebase your work
> against the
> latest trunk. Alternatively, if you're asked to make some
> changes,
> you can go back to the original Git commit and modify it
> until the
> project team accepts your changes.
> </p>
> </section>
>
> <section id="improvements">
> <title>Ongoing improvements</title>
> <p>
> Improvements to Git support at Apache are being discussed
> on the
> <a href="infra-mail.html">infrastructure-dev@ mailing list</
> a>.
> This list is open to everyone and is
> <a href="http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/
> "
>> publicly archived</a>. You can subscribe this mailing list by
> sending a message to
> <a href="mailto:infrastructure-dev-subscribe@apache.org?subject=subscribe
> "
>> infrastructure-dev-subscribe@apache.org</a>.
> </p>
> </section>
>
> </section>
> </body>
> </document>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt