Skip to content

Clarify which commit hash is used for backporting #254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 7, 2017
Merged

Clarify which commit hash is used for backporting #254

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
24e8622
Clarify which commit hash is used for backporting
Mariatta Aug 28, 2017
56ed121
Mention the git fetch upstream & git rev-parse combo
Mariatta Aug 28, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 28 additions & 12 deletions gitbootcamp.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -199,18 +199,6 @@ Solution::
$ git push --force origin some-branch


Backporting Merged Changes
--------------------------

A pull request may need to be backported into one of the maintenance branches
after it has been accepted and merged into ``master``. It is usually indicated
by the label ``needs backport to X.Y`` on the pull request itself.

Use the utility script `cherry_picker.py <https://github.com/python/core-workflow/tree/master/cherry_picker>`_
from the `core-workflow <https://github.com/python/core-workflow>`_
repository to backport the commit.


.. _git_from_mercurial:

Applying a Patch from Mercurial to Git
Expand Down Expand Up @@ -305,6 +293,34 @@ Pull requests can be accepted and merged by a Python Core Developer.
3. Press the ``Confirm squash and merge`` button.


Backporting Merged Changes
--------------------------

A pull request may need to be backported into one of the maintenance branches
after it has been accepted and merged into ``master``. It is usually indicated
by the label ``needs backport to X.Y`` on the pull request itself.

Use the utility script `cherry_picker.py <https://github.com/python/core-workflow/tree/master/cherry_picker>`_
from the `core-workflow <https://github.com/python/core-workflow>`_
repository to backport the commit.

The commit hash for backporting is the squashed commit that was merged to
the ``master`` branch. On the merged pull request, scroll to the bottom of the
page. Find the event that says something like::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I resolved conflict while cherry-picking to 3.6 branch, I want to use squash commit of 3.6 branch
for backporting to 3.5.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When backporting the squashed commit from master, we get to keep the reference to the original PR on master, so bedevere-bot can remove the needs backport to .. labels.

Does this happen when backporting from 3.6 to 3.5?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should - the trick in this case is that the "needs backport to 3.5" label should go on the backport PR against the 3.6 branch, rather than the original PR against master.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes things complicated for everyone.
If a core dev wants to backport from 3.6 to 3.5, they can do that at their own discretion, while making sure that labels are updated accordingly.
For everyone else (non core-devs backporting their own PR) I think it's best to recommend backporting from master.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, the only time it makes sense if when the backport from master fails, and even then, it only applies for security fixes, or the times when we have two full maintenance branches open (i.e. from beta 1 of the upcoming stable through to the release of that branch and the subsequent final full maintenance release of the now previous stable branch).

However, now that we branch at beta, we're likely to spend around 1/3rd of the time in that state.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Mariatta Clarifying: I don't think the above needs to be covered in this PR, but there are cases where we want to do X.Y -> X.Y-1 backports, rather than backporting directly from master.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks :) I'm going to merge this.


<coredeveloper> merged commit <commit_sha1> into python:master <sometime> ago.

By following the link to ``<commit_sha1>``, you will get the full commit hash.

Alternatively, the commit hash can also be obtained by the following git commands::

$ git fetch upstream
$ git rev-parse ":/bpo-12345"

The above commands will print out the hash of the commit containing ``"bpo-12345"``
as part of the commit message.


Editing a Pull Request Prior to Merging
---------------------------------------

Expand Down