> This actually might be considered a detriment. Let's say that you're > someplace you can review a change but not apply it. So you review it > and determine that it's good. Then the patch creator changes it in a > way that you don't find acceptable, but still passes all the tests.
When merging a pull request to a GitHub repo, you see all changes and commits right there in the GUI and can follow the evolution of the PR. If we were to mimic PR's using plain git (no HUB) then of course we'd need to first fetch and merge the remote branch, then review and test and finally commit. Should the PR author be requested to update his fix, he could do so in the same remote feature branch and a git pull by the committer would merge in the latest changes from that feature-branch. Takes some getting used to, but sounds compelling to me! > I'm pretty sure pull requests close over the current branch revision, so > there's no way to post ipso facto modify them from the sender's perspective. Well, take this GitHub PR of mine, I first opened the request, then added another commit to it before Nolan merged it in: https://github.com/healthonnet/hon-lucene-synonyms/pull/19 > But us accepting pull requests from github is completely distinct from > whether we use svn or git as a version control system: using git > doesnt even make it easier. Sure, it's just another channel for contributions. We can still work with patch files in JIRA. There may be a few git steps (remote add, fetch, checkout) to pull down the remote code which takes some time getting used to, but all this is made up for due to Git's super-fast branching. No need to have a bunch of duplicate svn checkouts lying around or wait for svn to checkout or merge... -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
