stefanha / git-publish Goto Github PK

I tried sending some QEMU patches today and the CC list was suspiciously empty.

Running git format-patch --no-cover-letter master followed by scripts/get_maintainer.pl --noroles --norolestats --nogit --nogit-fallback 2>/dev/null *.patch resulted in a list of email addresses.

I'm running git-publish on Fedora 35, installed from RPM package. There was an update to 1.8.0 on 2022-04-25, and the previous time I sent out QEMU patches on 2022-04-20 everything worked fine.

I tried running git-publish 1.8.0 from a git clone, same behavior. I reverted back to 1.7.0 and the CC list is once again populated.

7155b54 changes how cccmd is invoked, so that'd be my first guess at a culprit.

Patch
https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg07570.html
and
https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg07571.html

Stopping so you can inspect the patch emails:
cd C:\Users\lygstate\AppData\Local\Temp\tmph3bhg60q

[PATCH] cirrus: upgrade mingw base packages.
(mbox) Adding cc: Yonggang Luo [email protected] from line 'From: Yonggang Luo [email protected]'
(body) Adding cc: Yonggang Luo [email protected] from line 'Signed-off-by: Yonggang Luo [email protected]'

To: [email protected]
Cc: QEMU Trivial [email protected],Alex Bennижe [email protected], Philippe Mathieu-Daudиж [email protected], Thomas Huth [email protected], Wainer dos Santos Moschetta [email protected], Beraldo Leal [email protected]

[c] Edit Cc list in editor (save after edit)
[t] Edit To list in editor (save after edit)
[e] Edit patches in editor
[s] Select patches to send (default: all)
[p] Print final email headers (dry run)
[a] Send all
[q] Cancel (quit)
a
warning: ----------------- SECURITY WARNING ----------------
warning: | TLS certificate verification has been disabled! |
warning: ---------------------------------------------------
warning: HTTPS connections may not be secure. See https://aka.ms/gcmcore-tlsverify for more information.
fatal: 鍙厑璁糕€渉ttp鈥濆拰鈥渉ttps鈥濇柟妗堛€?
鍙傛暟鍚? requestUri
Sent [PATCH] cirrus: upgrade mingw base packages.
按 Enter 键继续...:

IIUC, when sending emails, the default CC list is found by looking at combination of Signed-off-by tags in the commit message, and results of an external script (eg qemu's get_maintanier.pl)

There are quite a few other commit message tags that are in common use - acked-by, reported-by, tested-by, reviewed-by and suggested-by in particular.

Here is info from QEMU's git history:

2949 acked-by:
1 acked-off-by:
5 analyzed-by:
3 approximately-suggested-by:
4 co-authored-by:
1 edited-by:
2 eviewed-by:
1 fine-with-me'd-by:
1 fix-suggested-by:
3 found-by:
1 inspired-by:
1 original-patch-by:
1 problem-spotted-by:
2 proposed-by:
2 rebased-by:
1 release-acked-by:
1 reported-and-analyzed-by:
3 reported-and-tested-by:
1686 reported-by:
1 reportyed-by:
7 requested-by:
2 reveiwed-by:
1 revieed-by:
1 revieved-by:
5 reviewd-by:
27289 reviewed-by:
1 reviewed-by::
2 reviewed-off-by:
3 reviwed-by:
1 rported-by:
1 sgined-off-by:
1 sigend-off-by:
1 signed-by:
1 signed-of-by:
5 signed-off
91069 signed-off-by:
1 signer-off-by:
4 singed-off-by:
1 spotted-by:
583 suggested-by:
1669 tested-by:
1 tested-off-by:
1 xsigned-off-by:

I would like to suggest that instead of only looking for S-o-B, it look for anything matching

XXXXXXX-by: name <email>

For any value of XXXXX - these tags are being added by patch authors because the person listed had some input on the work, so these people should be CC'd on the patch postings IMHO.

#32 added an 's' command in the inspect menu which allows selecting patches for sending. this is broken - the modified patches variable is used in the inspect menu, but not propagated back to line #734. instead of sending the subset of patches that were selected, all patches are sent. the check for modified patch files does not trigger, because the patch files are not removed.

I am not enough of a python person to know how to implement this correctly, but IMHO:

• the value of patches need to be propagated back from the inspect menu to the call site
• upon hitting "send all", all non-selected patch files should be removed from the tmpdir

ideally, the 's' command handling would re-initialize the tmpfile used for selection using all patches, not just the selected ones. this would allow selecting a subset, but then re-including a patch that was deselected without restarting the whole git-publish process.

See for example this cover letter:
https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg01296.html

  io_uring: retry io_uring_submit() if it fails with errno=3DEINTR
  io_uring: use io_uring_cq_ready() to check for ready cqes

Patch content and subject are however correct:
https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg01297.html

[PULL 01/11] io_uring: retry io_uring_submit() if it fails with errno=EINTR

It might be nice to allow for a meta-language in blurbs that facilitate a primitive post-processing.

For example,

*** YOUR BLURB HERE ***

Could be something like this:

YOUR COVER LETTER HERE

{diffstat}

Where {diffstat} invokes a hook to perform some known action (like git-backport-diff -r '@{u}..' -u my-topic-v{N-1}) and replaces that section with the output from the hook.

When editing the blurb, you'd leave {diffstat} in to allow it to be populated when sending, but not saved for future versions.

In the past, I've also scripted appending things like "And here's where this git branch is mirrored on github, for convenience" that could also take the form of another templating hook.

Reproducer can be found at: ehabkost@7a7c95f

If the cover letter has non-ascii characters, git-publish crashes with:

Traceback (most recent call last):
  File "/tmp/tmp.5mwl8IOgKs/bin/git-publish", line 905, in <module>
    sys.exit(main())
  File "/tmp/tmp.5mwl8IOgKs/bin/git-publish", line 851, in main
    open(cover_letter_path, 'wb').write(msg.as_bytes())
  File "/usr/lib64/python3.8/email/message.py", line 178, in as_bytes
    g.flatten(self, unixfrom=unixfrom)
  File "/usr/lib64/python3.8/email/generator.py", line 116, in flatten
    self._write(msg)
  File "/usr/lib64/python3.8/email/generator.py", line 181, in _write
    self._dispatch(msg)
  File "/usr/lib64/python3.8/email/generator.py", line 214, in _dispatch
    meth(msg)
  File "/usr/lib64/python3.8/email/generator.py", line 432, in _handle_text
    super(BytesGenerator,self)._handle_text(msg)
  File "/usr/lib64/python3.8/email/generator.py", line 249, in _handle_text
    self._write_lines(payload)
  File "/usr/lib64/python3.8/email/generator.py", line 155, in _write_lines
    self.write(line)
  File "/usr/lib64/python3.8/email/generator.py", line 406, in write
    self._fp.write(s.encode('ascii', 'surrogateescape'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 18-19: ordinal not in range(128)

Bisected to commit 0f2dd0b.

Example output when running git publish --to ehabkost --suppress-cc=all --verbose:

[...]
git tag --annotate --file /tmp/tmp0th878hm --force work/fix-header-warning-staging
git config branch.work/fix-header-warning.gitpublishprefix
git config format.subjectprefix
git tag -l --format=%(contents) work/fix-header-warning-staging
git log --no-color --oneline master..
git format-patch --subject-prefix "PATCH v4" --output-directory /tmp/tmpeqpwunoe --numbered --cover-letter master..
Stopping so you can inspect the patch emails:
  cd /tmp/tmpeqpwunoe

git send-email --to ehabkost --to [email protected] --suppress-cc all --dry-run --relogin-delay=0 --confirm=never /tmp/tmpeqpwunoe/0000-cover-letter.patch /tmp/tmpeqpwunoe/0001-Use-isystem-for-linux-headers-dir.patch /tmp/tmpeqpwunoe/0
002-mmap-alloc-Include-osdep.h-before-checking-CONFIG_LI.patch
[PATCH v4 0/2] Fix MAP_SYNC support when host has older glibc version
[PATCH v4 1/2] Use -isystem for linux-headers dir
[PATCH v4 2/2] mmap-alloc: Include osdep.h before checking CONFIG_LINUX

To: ehabkost
    [email protected]

[c] Edit Cc list in editor (save after edit)
[t] Edit To list in editor (save after edit)
[e] Edit patches in editor
[s] Select patches to send (default: all)
[p] Print final email headers (dry run)
[a] Send all
[q] Cancel (quit)
p

Stopping so you can inspect the patch emails:
  cd /tmp/tmpeqpwunoe

git send-email --to ehabkost --to [email protected] --suppress-cc all --dry-run --relogin-delay=0 --confirm=never /tmp/tmpeqpwunoe/0000-cover-letter.patch /tmp/tmpeqpwunoe/0001-Use-isystem-for-linux-headers-dir.patch /tmp/tmpeqpwunoe/0
002-mmap-alloc-Include-osdep.h-before-checking-CONFIG_LI.patch
[PATCH v4 0/2] Fix MAP_SYNC support when host has older glibc version
[PATCH v4 1/2] Use -isystem for linux-headers dir
[PATCH v4 2/2] mmap-alloc: Include osdep.h before checking CONFIG_LINUX

To: ehabkost
    [email protected]
[...]

This is why dry-run is failing:

$ git send-email --to ehabkost --to [email protected] --suppress-cc all --dry-run --relogin-delay=0 --confirm=never /tmp/tmpeqpwunoe/0000-cover-letter.patch /tmp/tmpeqpwunoe/0001-Use-isystem-for-linux-hea
ders-dir.patch /tmp/tmpeqpwunoe/0002-mmap-alloc-Include-osdep.h-before-checking-CONFIG_LI.patch
`batch-size` and `relogin` must be specified together (via command-line or configuration option)

Don't know if you're in a position to chase this, but it looks like the package has been pulled from debian-testing because the Debian package hasn't been updated to depend on python 3:

https://tracker.debian.org/pkg/git-publish

We've had a few encoding problems with Python 2:

• 24f3c38 Encoding tag annotate tmpfile with utf-8
• e736a2d Fix edit_email_list
• af8a192 Fix encoding of cc_cmd
• a62d6b0 Fix UTF-8 output decoding from git(1)

No effort has been spent on a full encoding problem audit. Python 3 is nowadays widely available so let's discuss the switch, which will hopefully fix it for good (the default encoding of Python 3 is "utf-8", among other improvements). Currently the shebang is #!/usr/bin/python which usually means Python 2.

Command line tools are usually accompanied by man pages to describe their usage, but git-publish lacks one right now.

Much of what is in README.rst could be turned into POD syntax from which a man page could be created.

This would be particularly helpful for making 'git publish --help' work as that just runs 'man git-$COMMAND', so currently you get

$ git publish --help
No manual entry for git-publish

Feature request

I found myself sending series with uncommitted changes few times already. As I believe it happened to others, maybe displaying a dumb warning would be useful to all.

This happened when I wrote the patches, then while writing the cover in git-publish I figure out a better way, so I rework the patches, then git-publish again to modify the cover message but forgot to commit the unstaged changes...

Anyway this is a selfish feature request, so I might implement it one day and add an issue here to not forget about it. Any quicker volunteer welcome to beat me at it :)

When the cover letter editor opens there is not much information on the name of the patch series, the revision number, the To/Cc lists, etc. Add this information in comments (that will not be included when the emails are sent) to give the user cues about what is going on.

Suggested-by: David Gibson [email protected]

Quoting @jnsnow , at https://lore.kernel.org/qemu-devel/[email protected]/

On 10/31/19 11:02 AM, Peter Maydell wrote:

Hi -- this passed the merge tests but it looks like you forgot
to add your signed-off by line as the submaintainer to Sam's
patches. Could you fix that up and resend, please?

thanks
-- PMM

I bit myself twice with this now: adding --signoff to a pull request
signs the messages that get sent to list, but not the ones that get staged.

Could always be a bug in my local copy, but I'm documenting it on the
list, in case I don't get time to look at this in the next 24h.

[p] Print final email headers (dry run)
[a] Send all
[q] Cancel (quit)
t
git var GIT_EDITOR
Traceback (most recent call last):
File "C:\work\xemu\xemu-opengl\qemu\xemu\git-publish", line 933, in
sys.exit(main())
File "C:\work\xemu\xemu-opengl\qemu\xemu\git-publish", line 890, in main
selected_patches = inspect_menu(tmpdir, to, cc, patches, suppress_cc,
File "C:\work\xemu\xemu-opengl\qemu\xemu\git-publish", line 512, in inspect_menu
new_to_list = edit_email_list(to_list)
File "C:\work\xemu\xemu-opengl\qemu\xemu\git-publish", line 459, in edit_email_list
for line in open(tmpfile.name, "r").readlines():
PermissionError: [Errno 13] Permission denied: 'C:\Users\lygstate\AppData\Local\Temp\tmpiwaxp3ta.txt'
按 Enter 键继续...:

** SUBJECT HERE *** is not correctly replaced when Subject: is wrapped on multiple lines

git format-patch HEAD~ --cover-letter --subject-prefix="a very long long long long long long long long long test"

Produces:

Subject: [a very long long long long long long long long long test 0/1] ***
 SUBJECT HERE ***

This will miss the naive [s.replace('*** SUBJECT HERE ***', message[0]) for s in lines] search&replace.

Feature request

When respinning a pull request, we could use git-backport-diff to find unmodified patches,
and only send the new/modified ones.

Example: https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg06956.html

Feature request

When respinning a series, list in the cover the patches that don't contain Reviewed-by or Acked-by tags,
to help reviewers to look at them first (useful with long series).

Examples:
https://www.mail-archive.com/[email protected]/msg718482.html
https://www.mail-archive.com/[email protected]/msg718150.html

During git-rebase the HEAD does not reference a branch. git-publish --edit fails because the current branch cannot be determined. It should be possible to determine the rebase branch through other means so that git-publish --edit works.

Suggested-by: Laurent Vivier [email protected]

I sent my first pull request for QEMU with git-publish and the cover letter it wrote included an SSH URI scheme, because I didn't remember it would need a separate URI configured for pull vs push.

git-publish could usefully request confirmation before sending the pull request, if it finds only a SSH URI present, to prevent such mistakes.

This is a feature request. As git-publish store the subject in a git note, it could notice a change in subject between version and suggest the user to add a 'Supersedes' tag in the cover.

commit 46a519c removed the install instructions from the documentation. We need to document how to install git-publish somewhere.

How to reproduce:

Step 1:

$ g publish -v --to [email protected] -b master
git rev-parse --show-toplevel
git rev-parse --git-dir
git symbolic-ref --short HEAD
git tag -l tmp/testing-gipublish-v[0-9]*
git config --get-all branch.tmp/testing-gipublish.gitpublishcc
git config branch.tmp/testing-gipublish.gitpublishcccmd
git show --raw --no-color --pretty=medium tmp/testing-gipublish-staging
git config format.coverLetter
git log --no-color --oneline master..
git config core.hooksPath
git rev-parse --git-common-dir
git show --raw --no-color --pretty=medium tmp/testing-gipublish-staging
git tag -l tmp/testing-gipublish-v[0-9]*
git show --raw --no-color --pretty=medium tmp/testing-gipublish-v0
git tag -a -m  -f tmp/testing-gipublish-staging
git config branch.tmp/testing-gipublish.gitpublishprefix
git config format.subjectprefix
git show --raw --no-color --pretty=medium tmp/testing-gipublish-staging
git log --no-color --oneline master..
git format-patch --subject-prefix PATCH --output-directory /tmp/tmpwditwe --no-cover-letter master..
Stopping so you can inspect the patch emails:
  cd /tmp/tmpwditwe

git send-email --to [email protected] --dry-run --confirm=never /tmp/tmpwditwe
[PATCH] TEST PATCH

To: [email protected]

[c] Edit Cc list in editor (save after edit)
[t] Edit To list in editor (save after edit)
[e] Edit patches in editor
[p] Print final email headers (dry run)
[a] Send all
[q] Cancel (quit)

Step 2: In another terminal:

$ cd /tmp/tmpwditwe
$ vim *

Step 3: Don't make any changes, but keep vim open

Step 4:

a
git config core.hooksPath
fatal: /tmp/tmpwditwe/.0001-TEST-PATCH.patch.swp: 1: patch contains a line longer than 998 characters
warning: no patches were sent
$ 

git-publish --pull-request push a tag to the repository.
When this repository is hosted on Gitlab.com and has Continuous Integration enabled,
this triggers a new pipeline by default. Pipelines aren't free.
The option to not trigger pipelines is to use push using --push-option=ci.skip (see https://docs.gitlab.com/ee/user/project/push_options.html).

When git-publish --setup is executed from an arbitrary directory that is not a Git repository it reports an exception and quits:

fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Traceback (most recent call last):
  File "/home/nyoxi/root/bin/git-publish", line 674, in <module>
    sys.exit(main())
  File "/home/nyoxi/root/bin/git-publish", line 494, in main
    if not check_profile_exists(options.profile_name):
  File "/home/nyoxi/root/bin/git-publish", line 230, in check_profile_exists
    lines = git_config_with_profile('--get-regexp', '^gitpublishprofile\\.%s\\.' % profile_name)
  File "/home/nyoxi/root/bin/git-publish", line 224, in git_config_with_profile
    ''' % dict(gitpublish=os.path.join(git_get_toplevel_dir(), '.gitpublish'),
  File "/home/nyoxi/root/bin/git-publish", line 108, in git_get_toplevel_dir
    return _git('rev-parse', '--show-toplevel')[0]
IndexError: list index out of range

When someone (like me) forgets to create a topic branch, very nice and explanatory message appears:

Please use a topic branch, cannot version master branch

However if the base branch is not master, there is no output and the command succeeds. What's even more confusing is that when there is some patch on top of that, the editor is opened with the template and after exiting the editor the command just ends without any indication of what is going on or what happened.

I don't know what's the intended behavior here, but this confuses me: git-publish will never ask me for the tag description or use the one I set using git publish --edit, or even adds a default one like "Pull request", unless I use the --cover-letter option.

[qemu/x86>]$ git show x86-staging
tag x86-staging
Tagger: Eduardo Habkost <[email protected]>
Date:   Mon Mar 9 17:31:37 2015 -0300

X86 queue

X86 patches queued in the last few weeks. Mostly code cleanup and changes on
code assigning APIC ID.

commit 9886e834f47adabdbfd54ab606788ce7326e6779
Author: Eduardo Habkost <[email protected]>
[...]
[qemu/x86>]$ git publish --profile default --pull-request -b origin/master --annotate

You need a passphrase to unlock the secret key for
user: "Eduardo Habkost <[email protected]>"
4096-bit RSA key, ID 984DC5A6, created 2014-10-15

Counting objects: 1, done.
Writing objects: 100% (1/1), 796 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To [email protected]:ehabkost/qemu.git
 + 1b4bb31...5e252d0 x86-pull-request -> x86-pull-request (forced update)
8 files to edit

Then vim opens with the following message, and an empty tag description:

From 9886e834f47adabdbfd54ab606788ce7326e6779 Mon Sep 17 00:00:00 2001
From: Eduardo Habkost <[email protected]>
Date: Mon, 9 Mar 2015 17:37:17 -0300
Subject: [PULL 0/7] X86 patches
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The following changes since commit 277263e1b320d759a760ba6c5ea75ec268f929e5:

  Merge remote-tracking branch 'remotes/agraf/tags/signed-ppc-for-upstream' into staging (2015-03-09 14:04:14 +0000)

are available in the git repository at:

  https://github.com/ehabkost/qemu.git tags/x86-pull-request

for you to fetch changes up to 9886e834f47adabdbfd54ab606788ce7326e6779:

  target-i386: Require APIC ID to be explicitly set before CPU realize (2015-03-09 16:30:03 -0300)

----------------------------------------------------------------

----------------------------------------------------------------

[...]

Is this the intended behavior? I would never guess that the --cover-letter option affect tagging behavior of --pull-request and I had to read the source code to find out how it works.

Currently the settings on repository-provided .gitpublish file can't override settings from ~/.gitconfig because ~/.gitconfig has a higher priority.

I'm not sure yet if this should be considered a bug. The current behavior may be expected by users that want to override .gitpublish options in their ~/.gitconfig. Other users (myself included) may want their ~/.gitconfig files to hold only defaults for repositories that don't have a .gitpublish file.

I'm opening this issue so we discuss what to do. I don't mind keeping the existing behavior by now, but I think we can support both use cases with the right combination of configuration options. I will try to come up with a proposal later.

I lost a bunch of work documenting a patch after git send-email failed (because it didn't exist in the Git distribution I was using). send-email can fail for a number of other reasons, so this should be handled a little more gracefully by git-publish.

I will probably submit a patch for this at some point if nobody else beats me to it :)

After selecting option [s] Select patches to send (default: all) and exiting GIT_EDITOR(in my case vim) after saving git publish gives this error

Traceback (most recent call last):
  File "/home/glitz/.local/bin/git-publish", line 914, in <module>
    sys.exit(main())
  File "/home/glitz/.local/bin/git-publish", line 871, in main
    selected_patches = inspect_menu(tmpdir, to, cc, patches, suppress_cc,
  File "/home/glitz/.local/bin/git-publish", line 468, in inspect_menu
    output = git_send_email(to_list, cc_list, patches, suppress_cc,
  File "/home/glitz/.local/bin/git-publish", line 247, in git_send_email
    return _git_with_stderr(*args[1:])[0]
  File "/home/glitz/.local/bin/git-publish", line 86, in _git_with_stderr
    print('git ' + ' '.join(args))
TypeError: sequence item 9: expected str instance, bytes found

The new word wrap logic seems to confuse git-send-email, if the cover letter subject line doesn't fit immediately after "Subject:", but fits completely in a separate line.

Steps to reproduce:

1. Create cover letter with the following contents:

123456789 123456789 123456789 123456789 123456789 123456789
  
testing.

2. Run git-publish. e.g.:

$ git publish -b master --to [email protected]
[...]
Stopping so you can inspect the patch emails:
  cd /tmp/tmplorrwjuo

[PATCH 0/1] 123456789 123456789 123456789 123456789 123456789 123456789
[PATCH 1/1] test

To: [email protected]

[c] Edit Cc list in editor (save after edit)
[t] Edit To list in editor (save after edit)
[e] Edit patches in editor
[s] Select patches to send (default: all)
[p] Print final email headers (dry run)
[a] Send all
[q] Cancel (quit)
p
/tmp/tmplorrwjuo/0000-cover-letter.patch
/tmp/tmplorrwjuo/0001-test.patch
Stopping so you can inspect the patch emails:
  cd /tmp/tmplorrwjuo

[PATCH 0/1] 123456789 123456789 123456789 123456789 123456789 123456789
[PATCH 1/1] test

To: [email protected]

[c] Edit Cc list in editor (save after edit)
[t] Edit To list in editor (save after edit)
[e] Edit patches in editor
[s] Select patches to send (default: all)
[p] Print final email headers (dry run)
[a] Send all
[q] Cancel (quit)
a
No subject line in /tmp/tmplorrwjuo/0000-cover-letter.patch? at /usr/libexec/git-core/git-send-email line 720.

This is how the Subject line is formatted by git-publish in that case:

From: Eduardo Habkost <[email protected]>
Date: Mon, 31 Aug 2020 17:00:32 -0400
Subject:     
 [PATCH 0/1] 123456789 123456789 123456789 123456789 123456789 123456789

testing.

Eduardo Habkost (1):
  test

 b | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 b

--·
2.26.2

I get a traceback when entering 's' in the menu:

$ git publish
Stopping so you can inspect the patch emails:
  cd /tmp/tmp06j47hq2

..snip...

[c] Edit Cc list in editor (save after edit)
[t] Edit To list in editor (save after edit)
[e] Edit patches in editor
[s] Select patches to send (default: all)
[p] Print final email headers (dry run)
[a] Send all
[q] Cancel (quit)
s
Traceback (most recent call last):
  File "/usr/bin/git-publish", line 814, in <module>
    sys.exit(main())
  File "/usr/bin/git-publish", line 780, in main
    options.override_cc)
  File "/usr/bin/git-publish", line 479, in inspect_menu
    listfile.write("\n".join(patches))
  File "/usr/lib64/python3.6/tempfile.py", line 483, in func_wrapper
    return func(*args, **kwargs)
TypeError: a bytes-like object is required, not 'str'

Here's one example:

fidencio@laerte ~/src/upstream/osinfo-db $ git commit --allow-empty --signoff 
[wip/gitpublish_bug 6ec0de6] Fabiano Fidêncio
fidencio@laerte ~/src/upstream/osinfo-db $ git publish 
Stopping so you can inspect the patch emails:
  cd /tmp/tmp8zoabkwj

Traceback (most recent call last):
  File "/usr/bin/git-publish", line 416, in parse_header
    for h, c in header.decode_header(hdr):
  File "/usr/lib64/python3.7/email/header.py", line 80, in decode_header
    if not ecre.search(header):
TypeError: expected string or bytes-like object

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/git-publish", line 848, in <module>
    sys.exit(main())
  File "/usr/bin/git-publish", line 814, in main
    options.override_cc)
  File "/usr/bin/git-publish", line 452, in inspect_menu
    print(parse_header(m['subject']))
  File "/usr/bin/git-publish", line 422, in parse_header
    sys.stderr.write("Failed to parse email header: %s\n", hdr)
TypeError: write() takes exactly one argument (2 given)

this is a calltrace when not running at git repository (no .git dir)
it would be great to check this early and yell at it

$ git-publish
Traceback (most recent call last):
File "/usr/bin/git-publish", line 914, in
sys.exit(main())
File "/usr/bin/git-publish", line 632, in main
if not check_profile_exists(options.profile_name):
File "/usr/bin/git-publish", line 330, in check_profile_exists
lines = git_config_with_profile('--get-regexp', '^gitpublishprofile\.%s\.' % profile_name)
File "/usr/bin/git-publish", line 290, in git_config_with_profile
gitpublish = os.path.abspath(os.path.join(git_get_toplevel_dir(), '.gitpublish'))
File "/usr/bin/git-publish", line 149, in git_get_toplevel_dir
GIT_TOPLEVEL = _git_check('rev-parse', '--show-toplevel')[0]
File "/usr/bin/git-publish", line 72, in _git_check
raise GitError('ERROR: %s\n%s' % (cmdstr, '\n'.join(stderr)))
main.GitError: ERROR: git rev-parse --show-toplevel
fatal: not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Hi.

Since version 1.8.1 has been released, a new option --send-email-args have been added which would be very handy in some cases. For example, we are limited by a university mail server in the rate of mails we can send. Being able to use --send-email-args "--batch-size 1 --relogin-delay 10" when sending a large patch series would be very handy.

Would it be possible to release version 1.8.2 of git-publish?

If an stgit branch has a description and then you git publish the changes on this branch, no matter what you put in the cover
during the editing phase, the body of the cover letter displays the stgit description instead.

$ stg branch --description="THIS TEXT SHOULD NOT END UP IN THE GIT PUBLISH COVER LETTER"
$ git publish -b ${base_branch} --subject-prefix RFC
Stopping so you can inspect the patch emails:
[ put a valid subject and description of the series ]
cd /tmp/tmpppoyqbry
...
$ cd /tmp/tmpppoyqbry
$ cat 0000-cover-letter.patch
From: Greg Kurz [email protected]
Date: Wed, 24 Mar 2021 10:43:43 +0100
Subject: [RFC 0/8] virtio: Improve boot time of virtio-scsi-pci and virtio-blk-pci
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0

THIS TEXT SHOULD NOT END UP IN THE GIT PUBLISH COVER LETTER

Greg Kurz (8):
memory: Allow eventfd add/del without starting a transaction
virtio: Introduce virtio_bus_set_host_notifiers()
virtio: Add API to batch set host notifiers
virtio-pci: Batch add/del ioeventfds in a single MR transaction
virtio-blk: Fix rollback path in virtio_blk_data_plane_start()
virtio-blk: Use virtio_bus_set_host_notifiers()
virtio-scsi: Set host notifiers and callbacks separately
virtio-scsi: Use virtio_bus_set_host_notifiers()

hw/virtio/virtio-pci.h | 1 +
include/exec/memory.h | 48 ++++++++++++++++------
include/hw/virtio/virtio-bus.h | 7 ++++
hw/block/dataplane/virtio-blk.c | 26 +++++-------
hw/scsi/virtio-scsi-dataplane.c | 68 ++++++++++++++++++--------------
hw/virtio/virtio-bus.c | 70 +++++++++++++++++++++++++++++++++
hw/virtio/virtio-pci.c | 53 +++++++++++++++++--------
softmmu/memory.c | 42 ++++++++++++--------
8 files changed, 225 insertions(+), 90 deletions(-)

--
2.26.3

When invoked as a git subcommand, git-publish won't respect configuration overrides given on the git command line with the -c option. e.g.

git -c sendemail.smtpserver=smtp.example.com publish ...

Will still use the normal default smtp server, rather than the one given on the comand line.

I use a wrapper script with a bunch of -c overrides to distinguish between my upstream and downstream workflows, which makes it difficult to use git publish.

Feature request

Add the GitHub Feature request tag to this repository so user filling such request can tag them :)
(this is a feature request).

If the user has the following on .gitpublish:

[gitpublishprofile "SOMEPROFILE"]
to = SOMEBODY

and they run:

$ git-publish --profile SOMEPROFILE --to SOMEBODYELSE

and then run:

$ git-publish --profile SOMEPROFILE

I believe the intended recipient for the message is SOMEBODY, not SOMEBODYELSE, as 'to' is explicitly configured in the .gitpublish profile. But git-publish will send the message to SOMEBODYELSE instead of SOMEBODY.

Is this a bug or a feature?

Considering that a profile was explicitly chosen in the command-line using --profile, I believe the profile options should take precedence over any other options from other config files.

I'm trying to test a pull request email sending so I run with my own to address:

$ GNUPGHOME=/run/media/berrange/SecureDiskB1/gpg/ git publish --pull-request --to='[email protected]'

Stopping so you can inspect the patch emails:
  cd /tmp/tmp148iop9k

[PULL 0/6] Qio next patches
  (mbox) Adding cc: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <[email protected]> from line 'From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <[email protected]>'
[PULL 1/6] qio: rename qio_task_thread_result
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 2/6] qio: introduce qio_channel_add_watch_{full|source}
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 3/6] qio: store gsources for net listeners
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 4/6] qio: non-default context for threaded qtask
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 5/6] qio: non-default context for async conn
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 6/6] qio: non-default context for TLS handshake
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'

To: [email protected]
Cc: "Dr. David Alan Gilbert" <[email protected]>
    "Daniel P. Berrangé" <[email protected]>
    Paolo Bonzini <[email protected]>
    Juan Quintela <[email protected]>
    Eric Blake <[email protected]>
    Peter Maydell <[email protected]>
    "Marc-André Lureau" <[email protected]>
    Gerd Hoffmann <[email protected]>
    [email protected]
    [email protected]

[c] Edit Cc list in editor (save after edit)
[t] Edit To list in editor (save after edit)
[e] Edit patches in editor
[p] Print final email headers (dry run)
[a] Send all
[q] Cancel (quit)
c

Now I definitely don't want to CC all those people when I'm testing this PR, so I selected the 'c' option, it opens the editor and I can delete all the CC addresses, but after saving and exiting the editor, it prints a message saying its adding a bunch of people to the CC list again ....

Stopping so you can inspect the patch emails:
  cd /tmp/tmp148iop9k

[PULL 0/6] Qio next patches
  (mbox) Adding cc: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <[email protected]> from line 'From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= <[email protected]>'
[PULL 1/6] qio: rename qio_task_thread_result
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 2/6] qio: introduce qio_channel_add_watch_{full|source}
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 3/6] qio: store gsources for net listeners
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 4/6] qio: non-default context for threaded qtask
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 5/6] qio: non-default context for async conn
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'
[PULL 6/6] qio: non-default context for TLS handshake
  (mbox) Adding cc: Peter Xu <[email protected]> from line 'From: Peter Xu <[email protected]>'
  (body) Adding cc: Peter Xu <[email protected]> from line 'Signed-off-by: Peter Xu <[email protected]>'
  (body) Adding cc: Daniel P. Berrangé <[email protected]> from line 'Signed-off-by: Daniel P. Berrangé <[email protected]>'

To: [email protected]
Cc: "Daniel P. Berrangé" <[email protected]>

[c] Edit Cc list in editor (save after edit)
[t] Edit To list in editor (save after edit)
[e] Edit patches in editor
[p] Print final email headers (dry run)
[a] Send all
[q] Cancel (quit)

It doesn't not appear to have actually re-added Peter Xu to the CC list, despite what its claiming here, so these messages are a bit misleading.