GeezerVison is showing github.com — Instructions on merging maintenance branches · Issue #25 · matplotlib/matplotlib
Instructions on merging maintenance branches #25
Description
As I'm working through improvements to the gitwash instructions, another important piece needs to be written that existed in the old developer documentation is how to merge changes from the maintenance branches into master. I see that Darren is doing this periodically already, but the instructions should be made explicit so that a) Darren doesn't have to feel like a bottleneck in the process and b) it's usually better for the authors of the changes to merge to master themselves in case there are any conflicts or changes necessary to have them work in a different context. This is something we always encouraged during the SVN days that worked very well.
Activity
ddale commented on Mar 1, 2011
I find this relatively easy to do with git. Any time a pull request is filed, as part of the review we should consider whether it is being applied to the right branch. After merging into the maintenance branch, I think we should merge the maintenance branch into master at the same time.
efiring commented on Mar 1, 2011
Right, but I think Mike's point is that gitwash needs to include explicit instructions on how to do this. Gitwash seems to have concentrated on procedure for people submitting pull requests; it is incomplete with respect to exactly how those doing the pushing into the official repo should handle the requests, or any other push situations.
For example, in the case of a change made to the maintenance branch, there are three basic cases: 1) it can be merged to master with no changes; 2) it can be merged with some adjustments; 3) it should not be merged at all, perhaps because master has been changed in such a way as to make the maintenance change irrelevant or inappropriate.
jkseppan commented on Mar 1, 2011
Even in case 3) the merge should be made, with --strategy=ours so that the commit is shown as an ancestor of master. Otherwise a later merge would try to apply the commit.
WeatherGod commented on Mar 2, 2011
"Even in case 3) the merge should be made, with --strategy=ours so that the commit is shown as an ancestor of master. Otherwise a later merge would try to apply the commit."
This is valuable information that should be in the docs. I don't think I would have thought of that otherwise.
mdboom commented on Jun 15, 2011
I think the gitwash instructions are now in much better shape than they once were. Closing this bug.
added a commit that references this issue
on Dec 5, 2013This issue will close once commit 6041e99 is merged into the 'master' branch.6041e99
Metadata
Metadata
Development
No branches or pull requestsIssue actions