We have an official git mirror for the project, though - git.apache.org/lucene-solr. So if people want to use git to collaborate, they can clone that repository and create branches there.
I much prefer git to svn - I use staged adds, rebases and stashes all the time - but anyone can currently use that by setting up a git-svn bridge. I'm not sure we gain anything except headaches by migrating the entire repo. On 28 Oct 2012, at 12:38, Erick Erickson wrote: > I don't have stropng feelings either way. If it would allow better > collaboration > branch merging, etc., then sure. > > I'm assuming we'd be able to do pre/post move diffs, right?. > > What about reformatting at that point? It'd be one of the few times when > we would, I think, have all the code in the repository at once. Not insisting > on this, I've actually grown used to avoiding re-formatting too much. But it'd > be one of the least painful moments to reformat. Not painless, mind, but.... > > Erick > > On Sun, Oct 28, 2012 at 8:04 AM, Shai Erera <ser...@gmail.com> wrote: >> What I wish we could do is to truly collaborate on these branches. For >> instance, when we create a feature branch today (following an issue), then >> people are free to commit changes to the branch, without worrying about >> breaking the main branch or nightly builds. When it's time, the changes will >> be merged to the main branch. But what we lack today is true collaboration >> -- allow all those involved to commit changes to the branch, thereby >> creating a healthier collaboration atmosphere. When the main people involved >> are committers, this is not so felt, but if the main people involved are >> non-committers, it's not so fun (to them mostly). >> >> Yet, I don't think that it can work otherwise, from the legal side. When >> people post patches in JIRA, there's a little checkbox that they need to >> tick, granting the ASF rights for this code. There's no checkbox to tick >> when changes are committed (well, since committers sign an agreement with >> the ASF about code rights, there's like a virtual tiny checkbox that they >> tick at commit time). >> >> So, and without me being a lawyer or anything (!), how would that work if we >> move to GIT? If we don't allow other people to commit to "feature branches", >> because there might be code licensing issues, what will be the advantage of >> moving to GIT? >> >> I'm asking because IMO if we cannot do that (let non-committers commit to >> feature branches), there's no strong reason to move away from SVN. We all >> know it, feel comfortable with it, and what's most important -- it does the >> job that we need. >> >> Shai >> >> But throughout the development of a feature, it'd be great if we can let all >> those involved to commit freely to the branch, without going through >> patches. Is that possible with our current SVN setup (or can we modify it)? >> Is that >> >> On Sun, Oct 28, 2012 at 1:24 PM, Michael Wechner <michael.wech...@wyona.com> >> wrote: >>> >>> Am 28.10.12 10:57, schrieb Robert Muir: >>> >>>> On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner >>>> <michael.wech...@wyona.com> wrote: >>>> >>>>> I also had/have quite some trouble to get used to the git commandline, >>>>> although or maybe because I used SVN commandline for many years, but I >>>>> am >>>>> very glad now to be using git on other projects, because in particular >>>>> the >>>>> process in being able to do feature based branches with git helps so >>>>> much, >>>>> that I think it's definitely worth the price. >>>>> >>>> There's no one on this planet that can convince me git is technically >>>> better. >>> >>> >>> I am not talking about "technically better" (or maybe I misunderstand this >>> term), but >>> I am talking about "process". With git I can do the following: >>> >>> - Basically for every change (even in case it might just be a typo inside >>> documentation) I am creating a branch (which I can a "feature" branch) >>> - I can share these branches easily with other people even if they don't >>> have commit/push access to the master branch and hence collaborate >>> - I can merge branches easily and in particular merge the master branch >>> into my feature branches, and hence keep my feature branches in sync, which >>> greatly simplies merging later on into the master branch >>> - I can commit stuff without having to be online, which is great when >>> doing several steps on the code, e.g. >>> - Commit one: Formatting changes >>> - Commit two: Functional changes >>> - Because of the above I can use a RTC (ReviewThenCommit) process, because >>> "others" can commit to feature branches, where I can review the code changes >>> and after successful review commit/push to the master branch. >>> >>> With SVN I couldn't do this that easily and because it wasn't easy, I >>> didn't do it. But git allowed me/us to change the process and for me >>> personally that is great. >>> >>> I think the question is what process do you want and what tool does make >>> this process simple? >>> >>> Maybe before argueing SVN versus git you should specify how you want to >>> collaborate and also specify requirements (as for example you point ou below >>> about speed). Once you have a clear picture about this, then consider the >>> various tools which exist. >>> >>> HTH >>> >>> Michael >>> >>>> I've used git on projects before. Its not that i have trouble getting >>>> used to it, its command line is genuinely horrible. >>>> >>>> And svn is absurdly fast for me: >>>> rmuir@beast:~/workspace$ time svn co >>>> https://svn.apache.org/repos/asf/lucene/dev/trunk >>>> real 0m23.454s >>>> user 0m5.712s >>>> sys 0m3.232s >>>> >>>> The speed of my internet connection makes git obselete. >>>> >>>> But if other people really like it, i won't stand in the way. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
