TypeError: %b requires a bytes-like object, or an object that implements __bytes

[kkmuffme]

Traceback (most recent call last):
  File "C:\python311\lib\site-packages\git_filter_repo.py", line 4976, in <modul
e>
    main()
  File "C:\python311\lib\site-packages\git_filter_repo.py", line 4973, in main
    filter.run()
  File "C:\python311\lib\site-packages\git_filter_repo.py", line 4892, in run
    self._parser.run(self._input, self._output)
  File "C:\python311\lib\site-packages\git_filter_repo.py", line 1527, in run
    self._parse_commit()
  File "C:\python311\lib\site-packages\git_filter_repo.py", line 1378, in _parse
_commit
    self._commit_callback(commit, aux_info)
  File "C:\python311\lib\site-packages\git_filter_repo.py", line 4125, in _tweak
_commit
    self._insert_into_stream(commit)
  File "C:\python311\lib\site-packages\git_filter_repo.py", line 4865, in _inser
t_into_stream
    self._parser.insert(obj)
  File "C:\python311\lib\site-packages\git_filter_repo.py", line 1505, in insert
    obj.dump(self._output)
  File "C:\python311\lib\site-packages\git_filter_repo.py", line 800, in dump
    file_.write((b'commit %s\n'
                ^^^^^^^^^^^^^^^
TypeError: %b requires a bytes-like object, or an object that implements __bytes
__, not 'NoneType'
fatal: stream ends early
fast-import: dumping crash report to .git/fast_import_crash_69216

For --force --refs "staging~17"..staging --email-callback '...'

[aswild]

I just ran into this too, looks like it's user error. The callback functions need to return byte-strings. From the man page:

One important thing to note for all callbacks is that filter-repo uses bytestrings (see https://docs.python.org/3/library/stdtypes.html#bytes) everywhere instead of strings.

In my case, I had to use --email-filter 'return b"..."' instead of --email-filter 'return "..."' and then it worked.

To the maintainers: perhaps git-filter-repo could produce a friendlier error message in cases like this?

For example, in RepoFilter._tweak_commit when the name/email callbacks are run, the code could check that the resulting values have a __bytes__ attribute, which (as far as I can tell) is what python uses when formatting b'%s'%(obj), as git-filter-repo later does in Commit.dump() which is seen in OP's backtrace.

Alternatively, git-filter-repo could check if the callbacks return a str and if so, automatically run it through str.encode('utf-8') to get a bytes object. That'd be user-friendly in the simple case, but I understand if that much additional "magic" isn't desirable.

[newren]

@kkmuffme

TypeError: %b requires a bytes-like object, or an object that implements bytes, not 'NoneType'
[...]
For --force --refs "staging~17"..staging --email-callback '...'

You didn't specify your email callback, but I suspect you forgot to include a return statement in it. If you could specify your email callback, I could verify or look for other problems.

I just ran into this too, looks like it's user error. The callback functions need to return byte-strings. From the man page:

One important thing to note for all callbacks is that filter-repo uses bytestrings (see https://docs.python.org/3/library/stdtypes.html#bytes) everywhere instead of strings.

In my case, I had to use --email-filter 'return b"..."' instead of --email-filter 'return "..."' and then it worked.

Thanks for commenting; my guess from the error they got is actually that they forgot the return statement, but this is a worthwhile problem to be aware of as well.

To the maintainers: perhaps git-filter-repo could produce a friendlier error message in cases like this?

maintainer, actually. There's just one of me. Anyway...

For callbacks like name, filename, message, email, or refname, it might be simple -- though potentially expensive since the callbacks are called so many times. And what about cases like commit or tag callbacks? Do we have to check every field of the resulting object that was operated on, since there's no way to know which field might have been modified? And do so every time the callback is called? While I like the idea of friendlier messages, I don't like the idea of introducing such overhead.