| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
The new key isn't signed with the old key so not accepted downstream,
and that's it as the old key literally broke and there is no backup.
|
|
|
|
| |
Related to https://github.com/gitpython-developers/gitdb/issues/77
|
|
|
|
|
|
|
|
| |
These weren't used by CI nor were they regularly tested.
If somebody misses something, we can bring them back of course.
This cleanup was triggered with the switch to pytest, and I wanted
to remove everything that was present just for nosetest.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a recent 'cleanup' operation that attempted to simplify my
GPG key workflow with Yubikeys, it looks like my GPG installation
has 'forgotten' how to interact with the key I typically used
to sign GitPython releases.
Since I never managed to establish a chain of trust with my only
remaining 'good' key, for you this means you cannot trust new
GitPython releases anymore.
There is nothing I can do about except to apologize for the hassle.
If you want to make constructive suggestions on how to fix this, I am
happy to work with you on that.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Due to me being in China and in an unexpected situation, I don't
have access to my gear, which would have included an adapter to
be able to use my USB-A yubikey (required for GitPython releases)
to USB-C of the Mac.
|
| |
|
| |
|
|
|
|
|
| |
Previously, master wasn't pushed, which might leave the commit
that bumps the version on disk. That is rather confusing then.
|
|
|
|
|
|
| |
At least on my system. So why not hardcode it
here.
Ideally this would be changed to docker or vitualenv.
|
|
|
|
| |
This re-release is just to get GPG signatures on releases.
|
| |
|
|
|