Hi Sven,
it is recommended practice that contributors create dedicated temporary branches for stuff that is intended to be merged. Due to their temporary nature, it is considered absolutely fine to
-
Rebase commits (especially when integrating upstream changes)
-
squash commits (mostly to clean up immediately before submitting a pull request)
-
delete the branch (once the request was merged)
Please find below some links to best-practices recommendations.
http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/
http://gun.io/blog/how-to-github-fork-branch-and-pull-request/
http://openshift.github.io/documentation-latest/oo_contributors_guide.html
Robert
From:
stardust-dev-bounces@xxxxxxxxxxx [mailto:stardust-dev-bounces@xxxxxxxxxxx] On Behalf Of
Sven.Rottstock@xxxxxxxxxxx
Sent: Dienstag, 4. Februar 2014 15:19
To: stardust-dev@xxxxxxxxxxx
Subject: Re: [stardust-dev] Moving Project Repositories to GitHub
I just found this blog entry:
https://dague.net/2013/05/23/github-vs-gerrit/
The question is really how does we want to handle pull requests which doesn’t pass our review? Does some workflows exists for this? How can we handle the following scenario
smoothly so that the contributor is not forced to flooding its Git log:
·
Contributor pushes its changes (Push1) into the forked project and creates a pull request
·
We reject this pull request because of wrong commit message format (maybe missing Signed-off-by line) or because the patch would break the code
·
Contributor commits/pushes some other things on top of Push1
So what should the contributor do if he wants to correct Push1? Create a branch which contains the fix and create a new pull request? This will blow up the history of the
Git repository of the contributor. Sure you can the delete this branch after we have accepted the pull request but this is an awful pattern for already published branches. Another solution could be to amend commits. But I’m not sure if it is working with already
pushed commits.
--
Sven
Hello everyone,
I would like to start a quick poll against the Stardust developer community regarding the above. I think here are strong arguments to make this move, especially with regard to lowering the barrier
of entry for new contributors.
On general, there would not be much change regarding day to day tasks:
-
The remote URL of your clone(s) would need to be adjusted to point to …github.org/… (detailed URLs to be announced)
-
Contributors would have to adopt the GitHub pull-request model (instead of opening requests against Gerrit)
-
Committers would have to review and merge pull-requests (instead of reviewing and accepting change requests against Gerrit)
Please find more background info here:
http://wiki.eclipse.org/Social_Coding/Hosting_a_Project_at_GitHub
Awaiting your feedback.
Best regards
Robert Sauer