RFE: Automated exportpatches tool, reverse of importpatches

[hroncok]

I'd like to be able to construct the content of a git branch from dist-git. If done nicely, we can automate creating tags in https://github.com/fedora-python/cpython whenever Koji build happens - that way we could stop caring about the tags and branch content manually and the entire workflow would be much simplicifed.

My idea for exportpatches is that it will:

1. look for the Python version in the spec file and git reset --hard to the appropriate @python/cpython v%{version} git tag
2. git am the patches from the spec file, one by one, ideally using --committer-date-is-author-date for a reproducible commit hash -- he commit messages are included in the patches, so we don't parse them from the specfile comments -- we only use the spec to get the list of patch files
3. create the fedora-%{version}-%{release} tag (release might as well contain the dist tag, so we can apply this behavior to diverged patches, like 251) and push it to @fedora-python/cpython (if enabled)
4. git reset --hard the fedora-%{version}to what we have just created and push force that one (if enabled)

I'd like to have this reproducible. When a new patch is added on top, we want a new commit on top, not an entirely fresh set of commits. I believe --committer-date-is-author-date should make that happen, but will see. Also when run from different machines, the commit hashes should remain identical.

[hroncok]

As for deployment, a MVP will require running the script from dist-git. Later we can iterate on top of that by fetching the latest builds from Koji daily or even responding to Koji builds by consuming some fedora-message kind of things, but that's out of scope here.

[hroncok]

If I manually git am existing patches we have on python3.11, I end up with different hashes. When I then imortpatches them back, this is the difference:

diff --git a/python3.11.spec b/python3.11.spec
index d8003bc..06da5d4 100644
--- a/python3.11.spec
+++ b/python3.11.spec
@@ -263,8 +263,7 @@ Source11: idle3.appdata.xml
 # (Patches taken from github.com/fedora-python/cpython)
 
 # 00001 # d06a8853cf4bae9e115f45e1d531d2dc152c5cc8
-# Fixup distutils/unixccompiler.py to remove standard library path from rpath
-# Was Patch0 in ivazquez' python3000 specfile
+# Fixup distutils/unixccompiler.py to remove standard library path from rpath Was Patch0 in ivazquez' python3000 specfile
 Patch1: 00001-rpath.patch
 
 # 00251 # 531494a5ded29dad59f617304dab4eb8b7f80b0b

Apparently, patch 1 has an inconsistency between the commit message in spec and in the patch.

I wonder how is that possible. When I manually format-patch it, the newline is gone. Heh :D

[hroncok]

Oh, alrighty, when adding --keep-subject to importpatches, I get patches that have reproducible hashes back and forth.

For the record, the subject of patch 1 changes this way:

-Subject: [PATCH] 00001: Fixup distutils/unixccompiler.py to remove standard
- library path from rpath Was Patch0 in ivazquez' python3000 specfile
+Subject: =?UTF-8?q?00001:=20Fixup=20distutils/unixccompiler.py=20to=20remo?=
+ =?UTF-8?q?ve=20standard=20library=20path=20from=20rpath=0AWas=20Patch0=20?=
+ =?UTF-8?q?in=20ivazquez'=20python3000=20specfile?=

I think that we can afford amending this commit message once, some to get rid of the weridness.

OTOH if we are to do this, we should probably use --keep-subject in importpatches to avoid various weirdness like this. It appears to affect all commits with messages where the second line is not empty.