You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Antoine Levy-Lambert <an...@gmx.de> on 2014/04/30 15:53:10 UTC
Hoped for advantages of migrating to git
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.
- 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.
- because of the popularity of git I imagine that the change is good for the long run but this is speculation
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.
Regards,
Antoine
Le 30 avr. 2014 01:57, Maarten Coene <ma...@yahoo.com> a écrit :
>
> Probably because I don't know much about git, but I don't see the real advantage of the switch from SVN to git.
> In addition, I don't have the time to help adapting the Ivy release process/scripts.
> But I don't want to stand in the way if everyone thinks this should be done.
>
> So, my vote is:
> for Ivy: -0
> for the rest: +0
>
> Maarten
Re: Hoped for advantages of migrating to git
Posted by Matt Sicker <bo...@gmail.com>.
Git is great for making small branches for things like bugfixes, features,
refactors, etc. That plus it's way faster than Subversion. Freaky fast.
On 30 April 2014 09:01, Josh Suereth <jo...@gmail.com> wrote:
> 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)
>
--
Matt Sicker <bo...@gmail.com>
Re: Hoped for advantages of migrating to git
Posted by Stefan Bodewig <bo...@apache.org>.
On 2014-05-07, Antoine Levy Lambert wrote:
> I don’t know whether an option of using only github and not the ASF
> hosted git is acceptable for the ASF ? for the Ant committers ?
For the ASF the only thing that matters is that the ASF git instance is
the source of truth. Tags are there and the source releases match the
tags inside the ASF git repo.
My personal preference is using the command line (or in fact magit)
rather than one-click merges in github, but that's me being a strange
kind of old fart. YMMV and I can certainly stick with the CLI even if
the rest of the team decided any other way.
> There is a file
> https://svn.apache.org/repos/private/committers/docs/github_team.txt
> which links the apache user ids of committers with their github ids, I
> wonder whether this linkage gives write access to the github mirrors
> of Apache projects ?
No, it doesn't. It associates your github account with your ASF account
so commits to ASF projects show up on your personal github page - and
you become a member of the apache org at github.
AFAIK there is no write access to the github mirrors.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Hoped for advantages of migrating to git
Posted by Matt Sicker <bo...@gmail.com>.
Yeah. You can get emails from GitHub for PRs, and the email always gives
the commands to pull it into your local repo and push it back to origin.
On 7 May 2014 22:55, Stefan Bodewig <bo...@apache.org> wrote:
> On 2014-05-07, Matt Sicker wrote:
>
> > The Camel project takes PRs from GH, though, so they may have some useful
> > info about that.
>
> http://camel.apache.org/contributing.html#Contributing-PullrequestatGithub
>
> sounds like manually merging the PR to the ASF git repo.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Hoped for advantages of migrating to git
Posted by Stefan Bodewig <bo...@apache.org>.
On 2014-05-07, Matt Sicker wrote:
> The Camel project takes PRs from GH, though, so they may have some useful
> info about that.
http://camel.apache.org/contributing.html#Contributing-PullrequestatGithub
sounds like manually merging the PR to the ASF git repo.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Hoped for advantages of migrating to git
Posted by Matt Sicker <bo...@gmail.com>.
I added my GH account info a while ago, but it only added my account to the
ASF organization on GH. It's kinda buggy with linking histories even, and
INFRA isn't too interested in resolving those issues since it's outside ASF.
The Camel project takes PRs from GH, though, so they may have some useful
info about that.
On Tuesday, 6 May 2014, Antoine Levy Lambert <an...@gmx.de> wrote:
> Matt, Jesse,
>
> I think that both of you are basically saying that accepting pull requests
> entered in github is going to be more manual work,
> including more command line work, in the case of a migration to
> git-wip-us.apache.org as opposed to migrating to use only github.
>
> I don’t know whether an option of using only github and not the ASF hosted
> git is acceptable for the ASF ? for the Ant committers ?
>
> Personally I am already glad to have seen support to migrate to git, and I
> would not want to push something more controversial.
>
> While github today is a very attractive platform, it could one day
> diverge from ASF policies or make other changes in their terms and
> conditions that we would dislike and not be able to influence.
>
> There is a file
> https://svn.apache.org/repos/private/committers/docs/github_team.txtwhich links the apache
> user ids of committers with their github ids, I wonder whether this
> linkage gives write access to the github mirrors
> of Apache projects ?
>
> Also, while researching this I found an interesting presentation by Jukka
> Zitting [1]
> and a mail message concerning Apache and Github [2]
> and also a wiki page from the Apache Cordova project [3]
>
> Best regards,
>
> Antoine
>
>
> [1]
> http://www.slideshare.net/jukka/apache-development-with-github-and-travis-ci
> [2]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201401.mbox/%3C596FFF55-6E33-4451-93D4-75ADD6CADCED@gmail.com%3E
> [3] http://wiki.apache.org/cordova/GitWorkflow
>
>
>
> On May 6, 2014, at 6:33 PM, Matt Sicker <boards@gmail.com <javascript:;>>
> wrote:
>
> > I mean how do you accept pull requests? You wouldn't be able to do it
> > through GitHub. You'd have to manually pull the branch from GitHub like
> the
> > name "pull request" implies. If you could commit to GitHub, then you
> could
> > add a remote besides origin for GitHub, then pull from the GitHub remote,
> > then push to the ASF remote (origin).
> >
> >
> > On 6 May 2014 01:45, Stefan Bodewig <bodewig@apache.org <javascript:;>>
> wrote:
> >
> >> On 2014-05-06, Matt Sicker wrote:
> >>
> >>> Git allows you to do both. You can auto-merge from GH, but I'm not
> >>> sure how you can even get write access to ASF GH repos.
> >>
> >> You don't, you commit to the ASF repo and it gets mirrored.
> >>
> >> IIRC some projects have their own forks of the ASF mirror and accept
> >> pull request on this fork. They then merge changes from their fork to
> >> the ASF repo.
> >>
> >> I'm not conviced I'd want to work that way, applying PRs without the
> >> Web-UI on a local checkout of the ASF git repo works fine for me.
> >>
> >> Stefan
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org <javascript:;>
> >> For additional commands, e-mail: dev-help@ant.apache.org <javascript:;>
> >>
> >>
> >
> >
> > --
> > Matt Sicker <boards@gmail.com <javascript:;>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@ant.apache.org <javascript:;>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Hoped for advantages of migrating to git
Posted by Matt Sicker <bo...@gmail.com>.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/user/repo branchname
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ant/1234.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1234
On 11 May 2014 15:05, Matt Sicker <bo...@gmail.com> wrote:
> And here's some more info about how to do that.
>
>
>
> On 11 May 2014 15:04, Matt Sicker <bo...@gmail.com> wrote:
>
>> I think it would work better to just do development on ASF, but accept
>> pull requests via GitHub somewhat manually. This is how it's done with
>> Apache Camel: http://camel.apache.org/contributing.html
>>
>> So it's done manually. Plus, nobody can write to the ASF GitHub repos
>> without pulling some strings in INFRA to do something about it, and I don't
>> think they like that idea anyhow due to the bylaws regarding what was
>> already said above.
>>
>>
>> On 7 May 2014 01:28, Jan Matèrne (jhm) <ap...@materne.de> wrote:
>>
>>> As a ASF project we MUST have a repo in Apache land:
>>> http://www.apache.org/dev/writable-git
>>> "ASF releases must be cut from the canonical ASF Git repositories."
>>>
>>> The absolute minimum is therefore:
>>> - working on somewhere else
>>> - starting a release:
>>> -- pull all changes to local
>>> -- push to ASF-repo
>>> -- create a branch/tag in the ASF repo for the release
>>> -- do the release
>>>
>>> But personally I prefer having one "right" repo in the ASF I could trust.
>>> Additional repos somewhere else (like on Github) could "just help".
>>>
>>> (If working with Git - would Gerrit a good candidate?)
>>>
>>>
>>> Jan
>>>
>>>
>>> > -----Ursprüngliche Nachricht-----
>>> > Von: Antoine Levy Lambert [mailto:antoine@gmx.de]
>>> > Gesendet: Mittwoch, 7. Mai 2014 02:18
>>> > An: Ant Developers List
>>> > Betreff: Re: Hoped for advantages of migrating to git
>>> >
>>> > Matt, Jesse,
>>> >
>>> > I think that both of you are basically saying that accepting pull
>>> > requests entered in github is going to be more manual work, including
>>> > more command line work, in the case of a migration to git-wip-
>>> > us.apache.org as opposed to migrating to use only github.
>>> >
>>> > I don’t know whether an option of using only github and not the ASF
>>> > hosted git is acceptable for the ASF ? for the Ant committers ?
>>> >
>>> > Personally I am already glad to have seen support to migrate to git,
>>> > and I would not want to push something more controversial.
>>> >
>>> > While github today is a very attractive platform, it could one day
>>> > diverge from ASF policies or make other changes in their terms and
>>> > conditions that we would dislike and not be able to influence.
>>> >
>>> > There is a file
>>> > https://svn.apache.org/repos/private/committers/docs/github_team.txt
>>> > which links the apache user ids of committers with their github ids, I
>>> > wonder whether this linkage gives write access to the github mirrors of
>>> > Apache projects ?
>>> >
>>> > Also, while researching this I found an interesting presentation by
>>> > Jukka Zitting [1] and a mail message concerning Apache and Github [2]
>>> > and also a wiki page from the Apache Cordova project [3]
>>> >
>>> > Best regards,
>>> >
>>> > Antoine
>>> >
>>> >
>>> > [1]
>>> http://www.slideshare.net/jukka/apache-development-with-github-and-
>>> > travis-ci
>>> > [2] http://mail-archives.apache.org/mod_mbox/lucene-
>>> > dev/201401.mbox/%3C596FFF55-6E33-4451-93D4-75ADD6CADCED@gmail.com%3E
>>> > [3] http://wiki.apache.org/cordova/GitWorkflow
>>> >
>>> >
>>> >
>>> > On May 6, 2014, at 6:33 PM, Matt Sicker <bo...@gmail.com> wrote:
>>> >
>>> > > I mean how do you accept pull requests? You wouldn't be able to do it
>>> > > through GitHub. You'd have to manually pull the branch from GitHub
>>> > > like the name "pull request" implies. If you could commit to GitHub,
>>> > > then you could add a remote besides origin for GitHub, then pull from
>>> > > the GitHub remote, then push to the ASF remote (origin).
>>> > >
>>> > >
>>> > > On 6 May 2014 01:45, Stefan Bodewig <bo...@apache.org> wrote:
>>> > >
>>> > >> On 2014-05-06, Matt Sicker wrote:
>>> > >>
>>> > >>> Git allows you to do both. You can auto-merge from GH, but I'm not
>>> > >>> sure how you can even get write access to ASF GH repos.
>>> > >>
>>> > >> You don't, you commit to the ASF repo and it gets mirrored.
>>> > >>
>>> > >> IIRC some projects have their own forks of the ASF mirror and accept
>>> > >> pull request on this fork. They then merge changes from their fork
>>> > >> to the ASF repo.
>>> > >>
>>> > >> I'm not conviced I'd want to work that way, applying PRs without the
>>> > >> Web-UI on a local checkout of the ASF git repo works fine for me.
>>> > >>
>>> > >> Stefan
>>> > >>
>>> > >> --------------------------------------------------------------------
>>> > -
>>> > >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For
>>> > additional
>>> > >> commands, e-mail: dev-help@ant.apache.org
>>> > >>
>>> > >>
>>> > >
>>> > >
>>> > > --
>>> > > Matt Sicker <bo...@gmail.com>
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > 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
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Hoped for advantages of migrating to git
Posted by Matt Sicker <bo...@gmail.com>.
And here's some more info about how to do that.
On 11 May 2014 15:04, Matt Sicker <bo...@gmail.com> wrote:
> I think it would work better to just do development on ASF, but accept
> pull requests via GitHub somewhat manually. This is how it's done with
> Apache Camel: http://camel.apache.org/contributing.html
>
> So it's done manually. Plus, nobody can write to the ASF GitHub repos
> without pulling some strings in INFRA to do something about it, and I don't
> think they like that idea anyhow due to the bylaws regarding what was
> already said above.
>
>
> On 7 May 2014 01:28, Jan Matèrne (jhm) <ap...@materne.de> wrote:
>
>> As a ASF project we MUST have a repo in Apache land:
>> http://www.apache.org/dev/writable-git
>> "ASF releases must be cut from the canonical ASF Git repositories."
>>
>> The absolute minimum is therefore:
>> - working on somewhere else
>> - starting a release:
>> -- pull all changes to local
>> -- push to ASF-repo
>> -- create a branch/tag in the ASF repo for the release
>> -- do the release
>>
>> But personally I prefer having one "right" repo in the ASF I could trust.
>> Additional repos somewhere else (like on Github) could "just help".
>>
>> (If working with Git - would Gerrit a good candidate?)
>>
>>
>> Jan
>>
>>
>> > -----Ursprüngliche Nachricht-----
>> > Von: Antoine Levy Lambert [mailto:antoine@gmx.de]
>> > Gesendet: Mittwoch, 7. Mai 2014 02:18
>> > An: Ant Developers List
>> > Betreff: Re: Hoped for advantages of migrating to git
>> >
>> > Matt, Jesse,
>> >
>> > I think that both of you are basically saying that accepting pull
>> > requests entered in github is going to be more manual work, including
>> > more command line work, in the case of a migration to git-wip-
>> > us.apache.org as opposed to migrating to use only github.
>> >
>> > I don’t know whether an option of using only github and not the ASF
>> > hosted git is acceptable for the ASF ? for the Ant committers ?
>> >
>> > Personally I am already glad to have seen support to migrate to git,
>> > and I would not want to push something more controversial.
>> >
>> > While github today is a very attractive platform, it could one day
>> > diverge from ASF policies or make other changes in their terms and
>> > conditions that we would dislike and not be able to influence.
>> >
>> > There is a file
>> > https://svn.apache.org/repos/private/committers/docs/github_team.txt
>> > which links the apache user ids of committers with their github ids, I
>> > wonder whether this linkage gives write access to the github mirrors of
>> > Apache projects ?
>> >
>> > Also, while researching this I found an interesting presentation by
>> > Jukka Zitting [1] and a mail message concerning Apache and Github [2]
>> > and also a wiki page from the Apache Cordova project [3]
>> >
>> > Best regards,
>> >
>> > Antoine
>> >
>> >
>> > [1] http://www.slideshare.net/jukka/apache-development-with-github-and-
>> > travis-ci
>> > [2] http://mail-archives.apache.org/mod_mbox/lucene-
>> > dev/201401.mbox/%3C596FFF55-6E33-4451-93D4-75ADD6CADCED@gmail.com%3E
>> > [3] http://wiki.apache.org/cordova/GitWorkflow
>> >
>> >
>> >
>> > On May 6, 2014, at 6:33 PM, Matt Sicker <bo...@gmail.com> wrote:
>> >
>> > > I mean how do you accept pull requests? You wouldn't be able to do it
>> > > through GitHub. You'd have to manually pull the branch from GitHub
>> > > like the name "pull request" implies. If you could commit to GitHub,
>> > > then you could add a remote besides origin for GitHub, then pull from
>> > > the GitHub remote, then push to the ASF remote (origin).
>> > >
>> > >
>> > > On 6 May 2014 01:45, Stefan Bodewig <bo...@apache.org> wrote:
>> > >
>> > >> On 2014-05-06, Matt Sicker wrote:
>> > >>
>> > >>> Git allows you to do both. You can auto-merge from GH, but I'm not
>> > >>> sure how you can even get write access to ASF GH repos.
>> > >>
>> > >> You don't, you commit to the ASF repo and it gets mirrored.
>> > >>
>> > >> IIRC some projects have their own forks of the ASF mirror and accept
>> > >> pull request on this fork. They then merge changes from their fork
>> > >> to the ASF repo.
>> > >>
>> > >> I'm not conviced I'd want to work that way, applying PRs without the
>> > >> Web-UI on a local checkout of the ASF git repo works fine for me.
>> > >>
>> > >> Stefan
>> > >>
>> > >> --------------------------------------------------------------------
>> > -
>> > >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For
>> > additional
>> > >> commands, e-mail: dev-help@ant.apache.org
>> > >>
>> > >>
>> > >
>> > >
>> > > --
>> > > Matt Sicker <bo...@gmail.com>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Hoped for advantages of migrating to git
Posted by Matt Sicker <bo...@gmail.com>.
I think it would work better to just do development on ASF, but accept pull
requests via GitHub somewhat manually. This is how it's done with Apache
Camel: http://camel.apache.org/contributing.html
So it's done manually. Plus, nobody can write to the ASF GitHub repos
without pulling some strings in INFRA to do something about it, and I don't
think they like that idea anyhow due to the bylaws regarding what was
already said above.
On 7 May 2014 01:28, Jan Matèrne (jhm) <ap...@materne.de> wrote:
> As a ASF project we MUST have a repo in Apache land:
> http://www.apache.org/dev/writable-git
> "ASF releases must be cut from the canonical ASF Git repositories."
>
> The absolute minimum is therefore:
> - working on somewhere else
> - starting a release:
> -- pull all changes to local
> -- push to ASF-repo
> -- create a branch/tag in the ASF repo for the release
> -- do the release
>
> But personally I prefer having one "right" repo in the ASF I could trust.
> Additional repos somewhere else (like on Github) could "just help".
>
> (If working with Git - would Gerrit a good candidate?)
>
>
> Jan
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Antoine Levy Lambert [mailto:antoine@gmx.de]
> > Gesendet: Mittwoch, 7. Mai 2014 02:18
> > An: Ant Developers List
> > Betreff: Re: Hoped for advantages of migrating to git
> >
> > Matt, Jesse,
> >
> > I think that both of you are basically saying that accepting pull
> > requests entered in github is going to be more manual work, including
> > more command line work, in the case of a migration to git-wip-
> > us.apache.org as opposed to migrating to use only github.
> >
> > I don’t know whether an option of using only github and not the ASF
> > hosted git is acceptable for the ASF ? for the Ant committers ?
> >
> > Personally I am already glad to have seen support to migrate to git,
> > and I would not want to push something more controversial.
> >
> > While github today is a very attractive platform, it could one day
> > diverge from ASF policies or make other changes in their terms and
> > conditions that we would dislike and not be able to influence.
> >
> > There is a file
> > https://svn.apache.org/repos/private/committers/docs/github_team.txt
> > which links the apache user ids of committers with their github ids, I
> > wonder whether this linkage gives write access to the github mirrors of
> > Apache projects ?
> >
> > Also, while researching this I found an interesting presentation by
> > Jukka Zitting [1] and a mail message concerning Apache and Github [2]
> > and also a wiki page from the Apache Cordova project [3]
> >
> > Best regards,
> >
> > Antoine
> >
> >
> > [1] http://www.slideshare.net/jukka/apache-development-with-github-and-
> > travis-ci
> > [2] http://mail-archives.apache.org/mod_mbox/lucene-
> > dev/201401.mbox/%3C596FFF55-6E33-4451-93D4-75ADD6CADCED@gmail.com%3E
> > [3] http://wiki.apache.org/cordova/GitWorkflow
> >
> >
> >
> > On May 6, 2014, at 6:33 PM, Matt Sicker <bo...@gmail.com> wrote:
> >
> > > I mean how do you accept pull requests? You wouldn't be able to do it
> > > through GitHub. You'd have to manually pull the branch from GitHub
> > > like the name "pull request" implies. If you could commit to GitHub,
> > > then you could add a remote besides origin for GitHub, then pull from
> > > the GitHub remote, then push to the ASF remote (origin).
> > >
> > >
> > > On 6 May 2014 01:45, Stefan Bodewig <bo...@apache.org> wrote:
> > >
> > >> On 2014-05-06, Matt Sicker wrote:
> > >>
> > >>> Git allows you to do both. You can auto-merge from GH, but I'm not
> > >>> sure how you can even get write access to ASF GH repos.
> > >>
> > >> You don't, you commit to the ASF repo and it gets mirrored.
> > >>
> > >> IIRC some projects have their own forks of the ASF mirror and accept
> > >> pull request on this fork. They then merge changes from their fork
> > >> to the ASF repo.
> > >>
> > >> I'm not conviced I'd want to work that way, applying PRs without the
> > >> Web-UI on a local checkout of the ASF git repo works fine for me.
> > >>
> > >> Stefan
> > >>
> > >> --------------------------------------------------------------------
> > -
> > >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For
> > additional
> > >> commands, e-mail: dev-help@ant.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > Matt Sicker <bo...@gmail.com>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Matt Sicker <bo...@gmail.com>
AW: Hoped for advantages of migrating to git
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
As a ASF project we MUST have a repo in Apache land:
http://www.apache.org/dev/writable-git
"ASF releases must be cut from the canonical ASF Git repositories."
The absolute minimum is therefore:
- working on somewhere else
- starting a release:
-- pull all changes to local
-- push to ASF-repo
-- create a branch/tag in the ASF repo for the release
-- do the release
But personally I prefer having one "right" repo in the ASF I could trust.
Additional repos somewhere else (like on Github) could "just help".
(If working with Git - would Gerrit a good candidate?)
Jan
> -----Ursprüngliche Nachricht-----
> Von: Antoine Levy Lambert [mailto:antoine@gmx.de]
> Gesendet: Mittwoch, 7. Mai 2014 02:18
> An: Ant Developers List
> Betreff: Re: Hoped for advantages of migrating to git
>
> Matt, Jesse,
>
> I think that both of you are basically saying that accepting pull
> requests entered in github is going to be more manual work, including
> more command line work, in the case of a migration to git-wip-
> us.apache.org as opposed to migrating to use only github.
>
> I dont know whether an option of using only github and not the ASF
> hosted git is acceptable for the ASF ? for the Ant committers ?
>
> Personally I am already glad to have seen support to migrate to git,
> and I would not want to push something more controversial.
>
> While github today is a very attractive platform, it could one day
> diverge from ASF policies or make other changes in their terms and
> conditions that we would dislike and not be able to influence.
>
> There is a file
> https://svn.apache.org/repos/private/committers/docs/github_team.txt
> which links the apache user ids of committers with their github ids, I
> wonder whether this linkage gives write access to the github mirrors of
> Apache projects ?
>
> Also, while researching this I found an interesting presentation by
> Jukka Zitting [1] and a mail message concerning Apache and Github [2]
> and also a wiki page from the Apache Cordova project [3]
>
> Best regards,
>
> Antoine
>
>
> [1] http://www.slideshare.net/jukka/apache-development-with-github-and-
> travis-ci
> [2] http://mail-archives.apache.org/mod_mbox/lucene-
> dev/201401.mbox/%3C596FFF55-6E33-4451-93D4-75ADD6CADCED@gmail.com%3E
> [3] http://wiki.apache.org/cordova/GitWorkflow
>
>
>
> On May 6, 2014, at 6:33 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> > I mean how do you accept pull requests? You wouldn't be able to do it
> > through GitHub. You'd have to manually pull the branch from GitHub
> > like the name "pull request" implies. If you could commit to GitHub,
> > then you could add a remote besides origin for GitHub, then pull from
> > the GitHub remote, then push to the ASF remote (origin).
> >
> >
> > On 6 May 2014 01:45, Stefan Bodewig <bo...@apache.org> wrote:
> >
> >> On 2014-05-06, Matt Sicker wrote:
> >>
> >>> Git allows you to do both. You can auto-merge from GH, but I'm not
> >>> sure how you can even get write access to ASF GH repos.
> >>
> >> You don't, you commit to the ASF repo and it gets mirrored.
> >>
> >> IIRC some projects have their own forks of the ASF mirror and accept
> >> pull request on this fork. They then merge changes from their fork
> >> to the ASF repo.
> >>
> >> I'm not conviced I'd want to work that way, applying PRs without the
> >> Web-UI on a local checkout of the ASF git repo works fine for me.
> >>
> >> Stefan
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For
> additional
> >> commands, e-mail: dev-help@ant.apache.org
> >>
> >>
> >
> >
> > --
> > Matt Sicker <bo...@gmail.com>
>
>
> ---------------------------------------------------------------------
> 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
Re: Hoped for advantages of migrating to git
Posted by Antoine Levy Lambert <an...@gmx.de>.
Matt, Jesse,
I think that both of you are basically saying that accepting pull requests entered in github is going to be more manual work,
including more command line work, in the case of a migration to git-wip-us.apache.org as opposed to migrating to use only github.
I don’t know whether an option of using only github and not the ASF hosted git is acceptable for the ASF ? for the Ant committers ?
Personally I am already glad to have seen support to migrate to git, and I would not want to push something more controversial.
While github today is a very attractive platform, it could one day
diverge from ASF policies or make other changes in their terms and conditions that we would dislike and not be able to influence.
There is a file https://svn.apache.org/repos/private/committers/docs/github_team.txt which links the apache
user ids of committers with their github ids, I wonder whether this linkage gives write access to the github mirrors
of Apache projects ?
Also, while researching this I found an interesting presentation by Jukka Zitting [1]
and a mail message concerning Apache and Github [2]
and also a wiki page from the Apache Cordova project [3]
Best regards,
Antoine
[1] http://www.slideshare.net/jukka/apache-development-with-github-and-travis-ci
[2] http://mail-archives.apache.org/mod_mbox/lucene-dev/201401.mbox/%3C596FFF55-6E33-4451-93D4-75ADD6CADCED@gmail.com%3E
[3] http://wiki.apache.org/cordova/GitWorkflow
On May 6, 2014, at 6:33 PM, Matt Sicker <bo...@gmail.com> wrote:
> I mean how do you accept pull requests? You wouldn't be able to do it
> through GitHub. You'd have to manually pull the branch from GitHub like the
> name "pull request" implies. If you could commit to GitHub, then you could
> add a remote besides origin for GitHub, then pull from the GitHub remote,
> then push to the ASF remote (origin).
>
>
> On 6 May 2014 01:45, Stefan Bodewig <bo...@apache.org> wrote:
>
>> On 2014-05-06, Matt Sicker wrote:
>>
>>> Git allows you to do both. You can auto-merge from GH, but I'm not
>>> sure how you can even get write access to ASF GH repos.
>>
>> You don't, you commit to the ASF repo and it gets mirrored.
>>
>> IIRC some projects have their own forks of the ASF mirror and accept
>> pull request on this fork. They then merge changes from their fork to
>> the ASF repo.
>>
>> I'm not conviced I'd want to work that way, applying PRs without the
>> Web-UI on a local checkout of the ASF git repo works fine for me.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Hoped for advantages of migrating to git
Posted by Matt Sicker <bo...@gmail.com>.
I mean how do you accept pull requests? You wouldn't be able to do it
through GitHub. You'd have to manually pull the branch from GitHub like the
name "pull request" implies. If you could commit to GitHub, then you could
add a remote besides origin for GitHub, then pull from the GitHub remote,
then push to the ASF remote (origin).
On 6 May 2014 01:45, Stefan Bodewig <bo...@apache.org> wrote:
> On 2014-05-06, Matt Sicker wrote:
>
> > Git allows you to do both. You can auto-merge from GH, but I'm not
> > sure how you can even get write access to ASF GH repos.
>
> You don't, you commit to the ASF repo and it gets mirrored.
>
> IIRC some projects have their own forks of the ASF mirror and accept
> pull request on this fork. They then merge changes from their fork to
> the ASF repo.
>
> I'm not conviced I'd want to work that way, applying PRs without the
> Web-UI on a local checkout of the ASF git repo works fine for me.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Hoped for advantages of migrating to git
Posted by Stefan Bodewig <bo...@apache.org>.
On 2014-05-06, Matt Sicker wrote:
> Git allows you to do both. You can auto-merge from GH, but I'm not
> sure how you can even get write access to ASF GH repos.
You don't, you commit to the ASF repo and it gets mirrored.
IIRC some projects have their own forks of the ASF mirror and accept
pull request on this fork. They then merge changes from their fork to
the ASF repo.
I'm not conviced I'd want to work that way, applying PRs without the
Web-UI on a local checkout of the ASF git repo works fine for me.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Hoped for advantages of migrating to git
Posted by Matt Sicker <bo...@gmail.com>.
Git allows you to do both. You can auto-merge from GH, but I'm not sure how
you can even get write access to ASF GH repos.
On Monday, 5 May 2014, Jesse Glick <ty...@gmail.com> wrote:
> On Mon, May 5, 2014 at 8:22 AM, Nicolas Lalevée
> <nicolas.lalevee@hibnet.org <javascript:;>> wrote:
> > once a committer is satisfied with the result, the work is being
> imported into the git repo with a script
>
> A much more straightforward workflow is just to do all work in the
> GitHub repo, accepting pull requests simply by pressing the Merge
> button, and have some cron process to push from the GH repo to the ASF
> repo—using the latter merely as a mirror to satisfy legal
> requirements, and acknowledging that GH is far more functional and
> pleasant to work with.
>
> I am not working on Ant these days (everything pertaining to my job
> uses Maven) so I have little personal stake; this is just a
> suggestion.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@ant.apache.org <javascript:;>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Hoped for advantages of migrating to git
Posted by Jesse Glick <ty...@gmail.com>.
On Mon, May 5, 2014 at 8:22 AM, Nicolas Lalevée
<ni...@hibnet.org> wrote:
> once a committer is satisfied with the result, the work is being imported into the git repo with a script
A much more straightforward workflow is just to do all work in the
GitHub repo, accepting pull requests simply by pressing the Merge
button, and have some cron process to push from the GH repo to the ASF
repo—using the latter merely as a mirror to satisfy legal
requirements, and acknowledging that GH is far more functional and
pleasant to work with.
I am not working on Ant these days (everything pertaining to my job
uses Maven) so I have little personal stake; this is just a
suggestion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Hoped for advantages of migrating to git
Posted by Nicolas Lalevée <ni...@hibnet.org>.
While I was getting to know better another ASF project Spark [1], I have found that they use git, and they heavily use github in their workflow. So I asked them how they work it it [2].
Of course the ASF git repo is the official source repo. But contributions are asked to go through github. A pull request is open there, discussion may happen there [3]. And once a committer is satisfied with the result, the work is being imported into the git repo with a script [4].
I am not suggesting we use that workflow or we shouldn't use it. It is just an interesting workflow I have found and which we may discuss.
Nicolas
[1] https://spark.apache.org/
[2] http://apache-spark-developers-list.1001551.n3.nabble.com/Mailing-list-td6451.html
[3] https://github.com/apache/spark/pull/634
[4] https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py
Le 1 mai 2014 à 02:19, Matt Sicker <bo...@gmail.com> a écrit :
> Apache projects are already mirrored at GitHub.
>
> https://github.com/apache/
>
> We just need better support for merging back from GitHub (or even being
> able to write to the GitHub repositories).
>
>
> On 30 April 2014 18:00, Andre-John Mas <an...@gmail.com> wrote:
>
>> Fair point.
>>
>> My experience has been the same. Was a little stubborn at first, but once
>> I made the move from Subversion I haven't looked back. One thing that I
>> found it fixed, in my environment, is avoiding devs using the main source
>> control as a form of backup.
>>
>> André-John
>>
>> Sent from my phone. Envoyé depuis mon téléphone.
>>
>>> On 30 Apr 2014, at 18:48, Josh Suereth <jo...@gmail.com> wrote:
>>>
>>> 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 <jo...@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
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Hoped for advantages of migrating to git
Posted by Matt Sicker <bo...@gmail.com>.
Apache projects are already mirrored at GitHub.
https://github.com/apache/
We just need better support for merging back from GitHub (or even being
able to write to the GitHub repositories).
On 30 April 2014 18:00, Andre-John Mas <an...@gmail.com> wrote:
> Fair point.
>
> My experience has been the same. Was a little stubborn at first, but once
> I made the move from Subversion I haven't looked back. One thing that I
> found it fixed, in my environment, is avoiding devs using the main source
> control as a form of backup.
>
> André-John
>
> Sent from my phone. Envoyé depuis mon téléphone.
>
> > On 30 Apr 2014, at 18:48, Josh Suereth <jo...@gmail.com> wrote:
> >
> > 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 <jo...@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
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Hoped for advantages of migrating to git
Posted by Andre-John Mas <an...@gmail.com>.
Fair point.
My experience has been the same. Was a little stubborn at first, but once I made the move from Subversion I haven't looked back. One thing that I found it fixed, in my environment, is avoiding devs using the main source control as a form of backup.
André-John
Sent from my phone. Envoyé depuis mon téléphone.
> On 30 Apr 2014, at 18:48, Josh Suereth <jo...@gmail.com> wrote:
>
> 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 <an...@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 <ni...@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 <jo...@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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Hoped for advantages of migrating to git
Posted by Josh Suereth <jo...@gmail.com>.
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 <an...@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 <ni...@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 <jo...@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
>
>
Re: Hoped for advantages of migrating to git
Posted by Andre-John Mas <an...@gmail.com>.
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 <ni...@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 <jo...@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 <an...@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/sbt and
>> 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
Re: Hoped for advantages of migrating to git
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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 <jo...@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 <an...@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/sbt and
> 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
Re: Hoped for advantages of migrating to git
Posted by Josh Suereth <jo...@gmail.com>.
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 <an...@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/sbt and
see how long it takes to switch branches / load the repository initially.
- The Peanut Gallery (Josh)