Thinking out loud... We are currently notified of pull requests - if we started using git, I would have two upstream repos - the apache repo and the github mirror.
Rather than use the one click pull github offers (I'd never use that anyway), I'd just add the guy as an upstream and merge in his change. Then I would commit and be done. He can make all the branches he wants and share them with whoever he wants. It's easy to pull changes from anywhere with git. I don't use any of the other github features, other than it's a central repo, and it provides a nice little way to request a pull. We have the pull requests anyway - if we document that was how you should contribute, we'd have a lot more of them. The problem is, I don't trust committing a patch i pull from git into svn. I still have to double check renames or any re-factoring is done right for svn, I have to worry about any binary file, and I have to run all the tests again. That keeps me from doing it anymore. For me that is the win - taking that out. I don't see a lot of other github benefits. The main benifit is that it provides nice hosting of code for any potential contributor that we can easily pull from. I see the benefits simply in a distributed version control system - and git is clearly the most popular one. Even now, as I check out a revision in svn to apply an old patch, I'm amazed at how long i have to wait when it would be done in no time with git. - Mark On Tue, Nov 6, 2012 at 9:15 AM, Jack Krupansky <j...@basetechnology.com> wrote: > One issue is how to use git and github. One can certainly use it as if it > were svn, but that misses a lot of the power of git, particularly the > collaborative tools on github. > > For example, one approach is to create a branch for every Jira ticket and > then instead of posting raw "patches" on the Jira ticket, create git "pull > requests" from the branch, which make it easy to comment on individual file > changes, right down to comments on individual lines of code. Changes can be > "committed" and pushed to the branch as work continues and new pull requests > generated. Eventually, pull requests can then be easily merged into the > master, as desired. Users can selectively include pull requests as they see > fit as well. > > But... can all of us, even non-committers do that? Or would the better > features of github be available only to committers? I don't know enough > about github to know whether you can have one class of user able to create > branches or comment on them but not merge into master or tagged branches > such as releases. > > -- Jack Krupansky > > > -----Original Message----- From: Mark Miller > Sent: Friday, October 26, 2012 7:02 PM > > To: dev@lucene.apache.org > Subject: Source Control > > So, it's not everyone's favorite tool, but it sure seems to be the most > popular tool. > > What are peoples thoughts about moving to git? > > Distributed version control is where it's at :) > > I know some prefer mercurial, but git and github clearly are taking over the > world. > > Also, the cmd line for git is a little eccentric - I use a GUI client called > SmartGit. Some very clever German's make it. > > A few Apache projects are already using git. > > I'd like to hear what people feel about this idea. > > - Mark > --------------------------------------------------------------------- > 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 > -- - Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
