Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
On Mon, 1 Jun 2020 at 13:25, Thomas Koenig <tkoe...@netcologne.de> wrote:
Am 01.06.20 um 14:20 schrieb Jonathan Wakely via Gcc:
It will only "keep" it for a matter of seconds, between that
backported commit and the backported fix. And unless you push the
first commit before pushing the fix, nobody will ever see the
regression without also seeing the fix (unless they specifically check
out the branch at the point of the first commit).
Or they do a regression hunt.
Which would specifically check out the branch at the point of the first
commit.
I thought it was policy not to have broken revisions on gcc.
Am I wrong?
We all commit broken revisions. And then fix them.
If you're concerned, squash them into a single commit. It's probably
not hard to alter the commit log to be a single entry that describes
the original change and the fix. You can always be more descriptive
(and even give the IDs of the original commits on master) in the
freeform text paragraphs before the ChangeLog entry.
I have done this for at least a pair of commits, the hook will accept
“Backport <sha1> and <sha1>” in that context.
(of course, you can use the verifier to check the commit message first as
well)
the manual process would be like this:
cherry pick ….
squash / rebase -i (including merging the commit message changelog fragments)
remove any changes to actual changelog files
AFAIU that’s it...
cheers
Iain
