Interesting discussion. At OPS4J.org we also (practically) flesh out processes to accept GIT projects (parallel to the usual Subversion offering). What we do differently is leveraging GitHub as some sort of outsourced tooling instead of maintaining our own. (This - i think - will never happen with ASF)
The idea is to use the best tools available for the job. For a Community its usually good to strive for talented developers and offer an environment where they like to work at. Also (thats a personal view) its something like a blueprint that corporates can learn from in terms of tooling, processes/communication. Its now the question to balance innovation (hence "coolness") and solid, well well known processes. Its also that Subversion is still the king in corporates (well, together with CVS). So you would attract a whole different kind of developers when adopting git. On the other hand you might lose attraction for the really successful (future) projects and/or setting standards for the next decade. Speaking of ASF, i think its worthwhile to think about it and maybe spike out a git incubator (say, "gincubator") that explores the benefits and pitfalls for ASF processes ? For regular podlings its not a question right now, as many have written here. just my 2cts. Toni ;) -- Toni Menzel || http://okidokiteam.com On Fri, Oct 1, 2010 at 11:09 AM, Enis Soztutar <enis.soz.nu...@gmail.com> wrote: > Wow, I haven't intended to start another flame war : ) > > From a technical standpoint, I do believe that git will be the default > choice of developers more and more > in the upcoming years, and Apache will start to support read-write git one > day. I was just curious if we can > volunteer to be the first podling (I think there is a discussion about using > git-only for some Apache labs projects). > > > Anyway, it seems that the discussions about git usage at the infra dev has > been settled > down to this: "switching to git is the most difficult thing in current > infra". So we should not expect > a first class git repo anytime soon I guess. > > But in the mean time, I was asking about whether any of the podlings use a > git only workflow, I mean > using git as the main tool and svn for commits only. And if so, do you > svn-copy branches and releases, > or use git for that. > > Thanks, > Enis > > On Fri, Oct 1, 2010 at 11:58 AM, Guillaume Nodet <gno...@gmail.com> wrote: > >> On Fri, Oct 1, 2010 at 10:45, Mark Struberg <strub...@yahoo.de> wrote: >> >> > > > I think it's really worse, as branches aren't maintained >> > > > anymore in the apache svn area, >> > >> > yes, and anyone ever asked yourself _why_ this happens? >> > The answer imo is: because its _sooo_ painful to do feature branches in >> SVN >> > (and merge them back). >> > >> >> Yes, this is the real reason ... and having an offline commit in svn won't >> solve that problem. >> >> >> > >> > GIT otoh has it's flaws too. There is e.g. no way to keep one big fat >> > unique Apache SVN where you can move around directories. This would have >> to >> > be done with git-submodules, which is much less handy. >> > >> > So I'm with Gav here: we need to evaluate this in multiple steps >> > >> > 1st) in theory, and later >> > 2nd) via an incubator podling project >> > >> > If it turns out that we cannot live with GIT, then we could still import >> > all the history of 'master' into our SVN. >> > >> > LieGrue, >> > strub >> > >> > >> > --- On Fri, 10/1/10, Guillaume Nodet <gno...@gmail.com> wrote: >> > >> > > From: Guillaume Nodet <gno...@gmail.com> >> > > Subject: Re: Podling to use native git >> > > To: general@incubator.apache.org >> > > Date: Friday, October 1, 2010, 8:20 AM >> > > On Fri, Oct 1, 2010 at 09:44, Gav... >> > > <ga...@16degrees.com.au> >> > > wrote: >> > > >> > > > >> > > > >> > > > > -----Original Message----- >> > > > > From: Guillaume Nodet [mailto:gno...@gmail.com] >> > > > > Sent: Friday, 1 October 2010 5:11 PM >> > > > > To: general@incubator.apache.org >> > > > > Subject: Re: Podling to use native git >> > > > > >> > > > > I do agree with you. I don't >> > > really get this argument either. >> > > > > >> > > > > But in the meantime, you need to use an svn >> > > backend, and ask for a git >> > > > > mirror. You can then fork >> > > / merge at github the way you want, merge >> > > > > back >> > > > > into trunk and git svn dcommit from there. >> > > > > >> > > > > I think it's really worse, as branches aren't >> > > maintained anymore in the >> > > > > apache svn area, >> > > > >> > > > What's wrong with 'git tag' ?? >> > > > >> > > >> > > What I'm saying is that having to maintain some branches at >> > > github outside >> > > of svn in git is not the best thing. But >> > > that's really the only option we >> > > have here. >> > > >> > > >> > > > >> > > > >> > > > > but that's what we need to live with until git >> > > can be >> > > > > properly supported at Apache. >> > > > >> > > > It will be a while. >> > > > >> > > > >> > > > Gav... >> > > > >> > > > > >> > > > > On Fri, Oct 1, 2010 at 08:49, Mark Struberg >> > > <strub...@yahoo.de> >> > > wrote: >> > > > > >> > > > > > Hmm, to be honest, I don't see this >> > > argument. Because you can also >> > > > > use a >> > > > > > centralised model with GIT. >> > > > > > >> > > > > > Also, the main benefit of GIT is not only >> > > that you can do offline >> > > > > commits, >> > > > > > but mostly that it's sooo much easier to >> > > merge! >> > > > > > I had a merge hell with my colleague in the >> > > company this week. He >> > > > > kept a >> > > > > > SVN feature branch for only one week and >> > > merging his feature branch >> > > > > into the >> > > > > > trunk (team with 10 developers) did cost us >> > > a whole day... >> > > > > > >> > > > > > The reason is that SVN applies an end to end >> > > diff while git aims to >> > > > > merge >> > > > > > by walking the commit tree of the branch and >> > > applying each commit >> > > > > > separately. >> > > > > > >> > > > > > GIT even supports signing off commits. So >> > > each committer who pushes >> > > > > to the >> > > > > > central repo 'signs' that the contribution >> > > is ASL licensed. >> > > > > > >> > > > > > LieGrue, >> > > > > > stru >> > > > > > >> > > > > > --- On Thu, 9/30/10, Noel J. Bergman <n...@devtech.com> >> > > wrote: >> > > > > > >> > > > > > > From: Noel J. Bergman <n...@devtech.com> >> > > > > > > Subject: RE: Podling to use native git >> > > > > > > To: general@incubator.apache.org >> > > > > > > Date: Thursday, September 30, 2010, >> > > 11:13 PM >> > > > > > > > Does any other podling use >> > > > > > > git-only workflow. >> > > > > > > >> > > > > > > No ASF project is permitted to use >> > > git-only. And the >> > > > > > > typical git workflow is part of the >> > > problem. We >> > > > > > > strongly believe in a single, central, >> > > repository as part of >> > > > > > > the process of community >> > > building. The git model is >> > > > > > > better suited to disparate groups >> > > partially sharing a >> > > > > > > codebase. >> > > > > > > >> > > > > > > Fundamentally, we WANT people working >> > > in a central, shared, >> > > > > > > repository. >> > > > > > > >> > > > > > > If/when the ASF allows git as a >> > > technology, you can expect >> > > > > > > that the workflow will be an ASF >> > > workflow. And once >> > > > > > > Greg gets offline commmit working with >> > > SVN, I suspect that >> > > > > > > it will be harder to push for git. >> > > > > > > >> > > > > > > --- Noel >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > ------------------------------------------------------------------- >> > > > > -- >> > > > > > > To unsubscribe, e-mail: >> general-unsubscr...@incubator.apache.org >> > > > > > > For additional commands, e-mail: >> > general-h...@incubator.apache.org >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > --------------------------------------------------------------------- >> > > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > > > > > For additional commands, e-mail: >> general-h...@incubator.apache.org >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Cheers, >> > > > > Guillaume Nodet >> > > > > ------------------------ >> > > > > Blog: http://gnodet.blogspot.com/ >> > > > > ------------------------ >> > > > > Open Source SOA >> > > > > http://fusesource.com >> > > > >> > > > >> > > > >> > > > >> > > --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > > > For additional commands, e-mail: general-h...@incubator.apache.org >> > > > >> > > > >> > > >> > > >> > > -- >> > > Cheers, >> > > Guillaume Nodet >> > > ------------------------ >> > > Blog: http://gnodet.blogspot.com/ >> > > ------------------------ >> > > Open Source SOA >> > > http://fusesource.com >> > > >> > >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > For additional commands, e-mail: general-h...@incubator.apache.org >> > >> > >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
