On 24/09/2012 21:00, Marvin Humphrey wrote:
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 remember that the permission system of Github "organizations" was very
coarse-grained initially. But it seems to have improved:
https://help.github.com/articles/what-are-the-different-access-permissions
But I guess the requirements of the ASF are more complex or simply
different.
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.
Yes, Git objects are always identified by their SHA hash. If git detects
a fast-forward merge, it will (by default) simply replay the commits
without creating a merge commit.
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.
+1
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.
There are of course more advanced ways to work with remote branches.
I'll try to document the general Git workflow on a Wiki page (creating
tracking branches, pushing to / pulling from remote branches). I always
found Git cheatsheets incredibly useful.
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.
+1
Nick
