On Fri, Nov 30, 2012 at 8:56 AM, Robert Muir <[email protected]> wrote:
> > > On Fri, Nov 30, 2012 at 8:50 AM, Per Steffensen <[email protected]>wrote: > >> Robert Muir skrev: >> >> Is it really git? Because its my understanding pull requests aren't >>> actually a git thing but a github thing. >>> >>> The distinction is important. >>> >> >> Actually Im not sure. Have never used git outside github, but at least >> part of it has to be git and not github (I think) - or else I couldnt >> imagine how you get the advantages you get. Remember that when using git >> you actually run a "repository" on every developers local machines. When >> you commit, you commit only to you local "repository". You need to "push" >> in order to have it "upstreamed" (as they call it) >> >> > Right, I'm positive this (pull requests) is github :) > > I just wanted make this point: when we have discussions about using git > instead of svn, I'm not sure it makes things easier on anyone, actually > probably worse and more complex. > > Its the github workflow that contributors want (I would +1 some scheme > that supports this!), but git by itself, is pretty unusable. > > Github is like a nice front-end to this mess. > > This is like a medicine to me! With all the craze about git (and we use it for our main project and also for solr development) it just confirms my 3 years-long experience. Git is pain. Github is great (too bad there is git behind it ;)) And now the problems of forks - with git the fork is the natural evil - git just makes it established practice. But it still doesn't save us from the (slow) process of incorporating new patches. While it is inevitable and we cannot be more grateful to all the committers for their hard work (really thanks!) perhaps there is a way to make solr/lucene more sandbox friendly? In our organization we are doing something similar (to using SOLR as a library), the automated build/deployment goes like this: - checkout our sources - download&build solr sources - compile our code - merge with solr & test - deploy This avoids forking solr and we always develop against the chosen branch, the pain was in porting the solr build infrastructure - if there was this infrastructure inside solr, ready for developers to take advantage of it, others were saved the pain or reinventing it. As far as I am aware, there is only one hard problem - the confusing nature of the classloaders inside webcontainers, i have really had hard time understanding it to make it right - but there are surely more knowledgeable people here. And if the worst comes to worst, the automated procedure could easily merge jars. Sounds evil? Is forking Solr a better way? roman
