ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Suereth <joshua.suer...@gmail.com>
Subject Re: Hoped for advantages of migrating to git
Date Wed, 30 Apr 2014 22:48:24 GMT
I'd argue that the convenience of pull requests in ASF should be a fixable
problem.  If ASF is running repositories, Gerrit would be a great way to
set up an elegant ASF workflow...

In any case, I applaud the effort to migrate to get and understand the
concerns.  My experience has been truly great moving to git.


On Wed, Apr 30, 2014 at 6:33 PM, Andre-John Mas <andrejohn.mas@gmail.com>wrote:

> Could we conceive of having a GitHub project, that serves as a point for
> pull-requests and other community work and at the same time have a git repo
> at Apache that syncs with this?
>
>
> André-John
>
> Sent from my phone. Envoyé depuis mon téléphone.
>
> > On 30 Apr 2014, at 17:33, Nicolas Lalevée <nicolas.lalevee@hibnet.org>
> wrote:
> >
> > Even if I share some of your enthusiasm with git, don't forget that git
> at the ASF isn't like git in github. Pull request, code review and so on is
> not as integrated as in github.
> >
> > Nicolas
> >
> >> Le 30 avr. 2014 à 16:01, Josh Suereth <joshua.suereth@gmail.com> a
> écrit :
> >>
> >> If you don't mind some recommendations from the peanut gallery (been
> using
> >> git for 5 years now)
> >>
> >>
> >> On Wed, Apr 30, 2014 at 9:53 AM, Antoine Levy-Lambert <antoine@gmx.de
> >wrote:
> >>
> >>>
> >>> Hello Maarten,
> >>>
> >>> I do not know a lot about git either.
> >>>
> >>> Here are the advantages I see in migrating to git :
> >>>
> >>> - git allows third-parties to clone an original repository and in fact
> to
> >>> create a fork while keeping the possibility of contributing back what
> they
> >>> have created if they want to, and also importantly to incorporate
> inside
> >>> their branches changes done elsewhere including in the reference
> >>> repository. So I see git as having the same strategic importance for
> the
> >>> source code like the fact of uploading the ant jars to maven central
> is for
> >>> the use of the binaries.
> >> This is pretty huge. The cost of contributions is a lot lower *and* you
> can
> >> perform magic on branches (git rebase) before submitting to upstream
> >> projects.  We (sbt + Scala) generally have a workflow of:
> >>
> >> 1. hack, hack, hack on our own clone/branch with a name "wip"
> >> 2. When done (across the group working on it), rebase the commits and
> clean
> >> up the commit messages to be as useful as possible
> >> 3. Submit a pull request, code review, go back to #1 as necessary
> >> 4. Merge into master, delete local branch, continue work.
> >>
> >> Not only that, we're already using the git Ivy mirror to collaborate
> >> between sbt devs and outside ivy contributors.  It's a very good model
> for
> >> highly distributed (i.e. OSS) teams where coordination of contributions
> is
> >> hard.
> >>
> >>
> >>> - for the developers of the Apache project - us - the small advantages
> are
> >>> to be able to commit stuff locally on our computers before pushing
> when we
> >>> are happy with our changes. Also one can switch branch very quickly
> within
> >>> the same workspace when using git, this might be an advantage.
> >> I often run 3-5 branches of code for OSS projects.  1-2 of "itch
> >> scratching" and 1-3 of "bug fixing".  It's a great thing.
> >>
> >>
> >>> - because of the popularity of git I imagine that the change is good
> for
> >>> the long run but this is speculation
> >> Popularity definitely puts it above something like mercurial.   It also
> >> means the tooling for git has become pretty good over the past few
> years.
> >> JGit even provides really good Git support for programatic access.
> >>
> >>
> >>
> >>> I imagine that some corporations, individuals,or other open source
> >>> organizations will take advantage of our projects moving to git to
> create
> >>> these forks, either because the contribution process via JIRA is too
> slow,
> >>> or because they want to create proprietary enhancements, or because
> they
> >>> are not sure that the changes that they do match the views /plans...
> of our
> >>> the Ant/Ivy/Ivyde/Easyant Apache project.
> >> From an sbt perspective, you'd see us attempting to contribute things
> back
> >> far more often than we do now.  If you'd like an example project that
> >> contains website assets in it, feel free to checkout github.com/sbt/sbtand
> >> see how long it takes to switch branches / load the repository
> initially.
> >>
> >> - The Peanut Gallery (Josh)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message