On Mon, Sep 24, 2012 at 6:12 AM, Nick Wellnhofer <[email protected]> wrote:
> The merge has to be done manually. +1 We can't accept a pull request directly into <https://github.com/apache/lucy.git> -- we need to update the canonical repo on Apache hardware and let the mirroring routines propagate the change out to Github. Also, it's inconvenient but we cannot close pull requests submitted against the Github mirror. This has to do with Github not offering permissions for organizations which are fine-grained enough to meet the needs of Apache. (If I understand correctly, the problem is that if individual PMC members get permission to close pull requests, they also get permission to do other stuff which Infra is not OK with.) I believe that if we commit a pull request without modifications, there's some sort of mechanism which detects that we have done so (presumably by examining commit SHAs) and closes the pull request automatically. But if we rebase or otherwise modify the commits, that won't happen. > This is easy if we're OK with non-linear > commit history or the pull request is based on the latest commit: > > git checkout master > git pull $repo_url $remote_branch > [ handle merge conflicts ] > git push origin master This is the debate I'd argued we should put off for a bit. The command sequence is certainly simpler in this case, but transitioning to a non-linear commit history has non-trivial implications. (Always `merge --no-ff`? Discipline for supporting `bisect`? Must all conflicts be handled in the merge commit? And so on...) > Otherwise, you'll have to fetch the remote branch and rebase it against > master. This is more complicated: > > # Fetch from remote repository > git fetch $repo_url $remote_branch:temp_branch > git checkout temp_branch > > # Rebase > git rebase master > [ handle rebase conflicts ] > > # Merge and push > git checkout master > git merge temp_branch > git push origin master > > # Cleanup > git branch -d temp_branch Nice recipe. :) If we were on Git already, I would follow it. As it stands, I'm just going to replay the commits manually on Subversion (after modifying the directory layout to use Moritz's suggestion), which will continue our existing linear commit history. In general what I explect to do going forward is... 1. Make a handful of commits to a feature branch in the Lucy ASF repo. 2. Gather consensus on the dev list if appropriate (because the change affects the public API or is a substantial enough change to the implementation). This might be done before or after before or after the initial commits to the feature branch. 3. If and when the feature passes muster, merge it to master. 4. Delete the feature branch. In this case, I used my Github fork to host the feature branch. I could also have used a branch in our current svn repo, but I wanted to audition the Github pull request apparatus and have this conversation. Marvin Humphrey
