DM-54042: Add some instructions for fast forward backporting #738
Conversation
|
@TallJimbo I'm not entirely happy with the text here, especially how people work out whether a fast forward will work. |
|
|
||
| .. note:: | ||
|
|
||
| If the release branch and the parent commit for this backport request are at the same commit, you do not need cherry pick commits onto the release branch and can instead fast forward the release branch. |
There was a problem hiding this comment.
I honestly don't know how to judge this PR or this statement.
There was a problem hiding this comment.
I think we could instead say, "if the release branch (or if it doesn't exist, the release tags) are on a commit that is also on the main branch and your ticket is the first one after that commit". A screenshot of this condition in some git GUI would really be worth a thousand variations of those words, though.
There was a problem hiding this comment.
I've added some example text in the section below (wasn't sure about adding even more to a note. I'll try to rephrase this sentence.
|
|
||
| .. note:: | ||
|
|
||
| If the release branch and the parent commit for this backport request are at the same commit, you do not need cherry pick commits onto the release branch and can instead fast forward the release branch. |
There was a problem hiding this comment.
I think we could instead say, "if the release branch (or if it doesn't exist, the release tags) are on a commit that is also on the main branch and your ticket is the first one after that commit". A screenshot of this condition in some git GUI would really be worth a thousand variations of those words, though.
|
|
||
| .. _backports-fast-forward: | ||
|
|
||
| What If The Backport Can Be Fast Forwarded? |
There was a problem hiding this comment.
If the fast-forward criteria is satisfied, maybe we should just instruct people to ask in a Slack channel for a pro to take over (#dm-build-support, perhaps?). I too like the fast-forward backports enough that I really do want to encourage them, but:
- they are some pretty deep git-fu until you get used to them;
- they sometimes require temporarily changing the branch protections, which not everyone can do (or not doing release branch protections, which has its own problems);
- I think some combination of you, me, and maybe @mwittgen could clear any such requests them quickly.
There was a problem hiding this comment.
Isn't it simpler to fast forward than follow the other instructions? In essence it's git merge commit-from-main. I think I've decided that the branch protections on v*.0.x branches that require pull requests are more painful than useful and I've been turning them off permanently.
timj
force-pushed
the
tickets/DM-54042
branch
from
e2e9754 to
28d0a43
Compare
No description provided.