npub1tkq8unhsd5jqx6ueex5lcpsgknrpquxuk44ftpjlpm3ulaake7xs76txrw/ngit-cli-mirror/src, branch v1.2.1Personal mirror of DanConwayDev/ngit-cli on git.upleb.uk
https://upleb.uk/npub1tkq8unhsd5jqx6ueex5lcpsgknrpquxuk44ftpjlpm3ulaake7xs76txrw/ngit-cli-mirror/atom?h=v1.2.12024-05-14T06:28:21+00:00fix: `ngit init` multiple maintainers2024-05-14T06:28:21+00:00DanConwayDevDanConwayDev@protonmail.com2024-05-14T06:28:21+00:00urn:sha1:6751d9377f853030633c9801735f33f31425326c
fixes:
nostr:nevent1qqsz2g7gexkmqgr0x4g5kf9py8vx06p8nyn78v7mhevprasnyfy5swcpp4mhxue69uhkummn9ekx7mqzyr7jprhgeregx7q2j4fgjmjgy0xfm34l63pqvwyf2acsd9q0mynuzdyll0c
feat(send): `in-reply-to` tags npubs and events2024-05-07T08:10:33+00:00DanConwayDevDanConwayDev@protonmail.com2024-04-22T06:26:15+00:00urn:sha1:10498b953d36304b441fcb162155c2487046206f
in addition to being used to create a new proposal revision,
in-reply-to can now be used to reference other events and npubs.
for example an issues or kind 1 threads where the proposal is relevant
the proposal will only be marked as a revision if the first parameter is
a reference to an existing proposal root
fix: remove relay.f7z.io from default relays2024-04-24T06:34:14+00:00DanConwayDevDanConwayDev@protonmail.com2024-04-24T06:34:14+00:00urn:sha1:c4853f69dc25408ff70cccbe923d2cd400385fc2
as over the last 2-3 weeks it has consitantly be timing out
feat(send): print link to proposal root2024-04-22T08:29:18+00:00DanConwayDevDanConwayDev@protonmail.com2024-04-22T08:29:18+00:00urn:sha1:6bfd8b0ddec7f8f4c24a97d357de9acd615b0b17
after a new root proposal has been sent
link directly to gitworkshop.dev as well as njump.me until
gitworkshop is added to njump
feat: reduce connection timeout 6s ~> 3s2024-04-10T10:41:00+00:00DanConwayDevDanConwayDev@protonmail.com2024-04-10T10:41:00+00:00urn:sha1:ba83cc575ec97c313841c79e2a1afd448d8b9fe5
seperate connection timeout from get_events_of timeout and reduce it to 3s
feat(init): support multiple git_servers2024-04-08T15:10:05+00:00DanConwayDevDanConwayDev@protonmail.com2024-04-01T14:43:30+00:00urn:sha1:4a5c32ba062ca6ba7fd27e89d2b2f46e4f2368fb
in line with initial merged nip34 spec
feat: reduce `get_events` timeout 10s ~> 6s2024-04-08T15:10:03+00:00DanConwayDevDanConwayDev@protonmail.com2024-04-01T14:24:29+00:00urn:sha1:8c5a484a0e010eaa566c17acd8b344114b68caa6
if relays do not connect and retun events within 3s
they will rarely connect at all
this could be reversed when get_events is used async
refactor: allow pedantic clippy warning large_futures2024-03-28T11:56:15+00:00DanConwayDevDanConwayDev@protonmail.com2024-03-28T08:30:57+00:00urn:sha1:4171733090d25732029a149cf0976c6b1103d0ea
rust-nostr author suggested this might be a false positive
https://github.com/rust-nostr/nostr/pull/375#issuecomment-2022245832
fix: relay connection timeout panic2024-03-27T17:19:01+00:00DanConwayDevDanConwayDev@protonmail.com2024-03-25T09:47:04+00:00urn:sha1:04a8bce2c58dfb697410ae9bb83ab6abbf95406a
upgrade from rust-nostr v0.27 ~> v0.28 introduces this panic
presumably get_events attempted to write to the MultiProgress
just after it has been removed
refactor: more concise error message2024-03-27T17:18:58+00:00DanConwayDevDanConwayDev@protonmail.com2024-03-22T16:02:35+00:00urn:sha1:761484b6db6100a8b7f81e09f8903232f9f3ffaf
to suppress the clippy too_many_lines in function warning