The commit then push workflow *is* what allows you to maintain multiple local branches without the nightmare of having multiple checkouts, and managing them.
I don't think that moving to GIT has anything to do with Github. With SVN, we also don't have any nice user interface and/or pull requests, so the lack of one in GIT is irrelevant in my opinion. If we consider moving to GIT, we might also want to look at using Gerrit for our code reviews and patch submissions. It makes the code review aspect much easier, nicer and helpful. Shai On Sat, May 30, 2015 at 12:36 PM, Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > > > I think most people say that GIT is easier or better to use because they > combine in their mind using „GIT“ with „the Github user interface“. > > > > This is indeed very nice to have - I (for myself) am also very happy with > using Github, as long as it keeps simple (you only have users from Github > sending you pull requests, if you only need to push to one location,…). On > the other hand, I always get annoyed that you cannot do the same like “svn > update” or “svn commit” in one turn. You always have to pull first and then > update or vice versa first commit then push. If you are online there is no > reason to have this separated, especially if you are a “committer”. If you > are contributor, that fine – because you cannot push, but for committers > this is what subversion people like me hate. And all these additional steps > are not useful to a “centralized” infrastructure like ASF. > > > > As said before, at the ASF, we don’t get the Github interface as “main > primary user interface”, because the “committers” have to use the official > ASF git installation to push. So we are still not able to easily handle > pull requests on github and so on. So there is no useful thing (except the > mentioned: no longer need to have multiple checkouts locally) with GIT. The > big backside is: without the Github Web interface, GIT is unuseable to me, > sorry. The command line is a disaster, technical concepts behind GIT are a > disaster; everything is a disaster J > > > > I would plus one to use Git, if we would solely use “GitHub” as central > repository (like Elasticsearch), but with having the “central > infrastructure” at the ASF: > > Clear -1 !!! > > > > Uwe > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Anshum Gupta [mailto:ans...@anshumgupta.net] > *Sent:* Friday, May 29, 2015 11:08 PM > *To:* dev@lucene.apache.org > *Subject:* Moving to git? > > > > I know this has come up a few times in the past but I wanted to bring this > up again. > > > > The lucene-solr ASF git mirror has been behind by about a day. I was > speaking with the infra people and they say that the size of the repo needs > more and more ram. Forcing a sync causes a fork-bomb: > > > > Can't fork: Cannot allocate memory at /usr/share/perl5/Git.pm line 1517. > > > > They tried a few things but it's almost certain that it needs even more > RAM, which still is a band-aid as they'd soon need even more RAM. Also, > adding RAM involves downtime for git.a.o which needs to be planned. As a > stop gap arrangement attached a volume to the instance and are using it as > swap to work around the "adding RAM requires restart" issue. > > > > FAQ: How would the memory requirement change if we moved to git instead of > mirroring? > > Answer: svn -> git mirroring is a weird process and has quite the memory > leak. Using git directly is much cleaner. > > > > I personally think git does make things easier to manage when you're > working on multiple overlapping things and so we should re-evaluate moving > to it. I would have been fine had the mirroring worked, as all I want is a > way to be able to work on multiple (local) branches without having to > create and maintain directories like: lucene-solr-trunk1, > lucene-solr-trunk2, or SOLR-XXXX, etc. > > > > Opinions? > > > > > > -- > > Anshum Gupta >
