Oddbean new post about login | logout Where can I see it? All I get is this: https://nostrcheck.me/media/fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1/393c6317517b6d700330ff5f3c251d2fd535d0ce07b649df2a910114af7ede4d.webp
Where can I find out the eventID, so that I can look at it someplace like njump or nostrudel? @Enki @cloud fodder Do your relays accept the ngit notes? Because those are my dev-npub's mailboxes.
The events from this NIP: https://github.com/nostr-protocol/nips/blob/master/34.md
Did you successfully send one? I cant see it on any relays. When you ran `ngit send` it would have told you if each relay accepted your patch event(s)
I think I have a problem because I have two different repos with the same name, but different source repos. One is a fork of the other
Isn't it confusing to maintain two different repos with the same name?
yes 😂 Never occured to me to rename them, since I've never maintained the source and the fork, before. Used to only work with branches on the source repo. I should go rename all my forks, so that I can identify them.
What are the purposes of the forks? Do they differ signifcantly? Why not have them as branches of the same repo?
We're using the same as branches, with each dev having a fork that they're working on and then making a PR to the source repo for merges. Just looks neater in the source.
Each dev would use the source repo to get the lastest changes. Then use `ngit send` to create proposal (PR equivalent) when they ready to share what they are working on. They can update the proposal with `ngit push` or after a rebase they can use `ngit push --force`. `git merge` can be used for merging into the master branch to be pushed to the source repo.
Okay, looks much better. 😅 I was so confused! Just prefacing my forks all with "sw_". https://gitworkshop.dev/repo/sw_gitcitadel
It only makes sense to have a nostr repo event for a distinct repository that you would want to receive proposals for or raise issues against. This typically wouldn't be one per developer.
Okay, so then it would only need to be the source repos and not my forks. That makes sense.
I'm going to keep testing on my fork, tho, to keep the source one neat. Let me go try to send something again and get you the output.
If a user-npub wrote me on Nostr with a bug, how do I turn that into an issue? With some sort of a quote or reply?
Hey, nostr:nprofile1qyfhwumn8ghj7un9d3shjtnxxaazu6t09uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyzsq3hh327t0h2dq6matqn5064cgj2zanl2stkj6s0lg4t2h5dty6xk8zw9 that markdown looks very pretty. I like that. Displays on GitWorkshop better than on GitHub.
Thanks.
This is what I got on the command: logged in as SilberWitch ✔ 1 events wss://nostr.sovbit.host/ ✔ 1 events wss://theforest.nostr1.com/ posting 1 patch with a covering letter... ✔ [my-relay] [repo-relay] wss://nostr.sovbit.host/ ✔ [my-relay] [repo-relay] wss://theforest.nostr1.com/ ✔ [default] wss://relay.damus.io ✔ [default] wss://nos.lol ✔ [default] wss://relay.nostr.band ✘ [default] wss://relay.f7z.io error: recv message response timeout
I just realized that I accidentally named the repo "SilberWitch" instead of gitcitadel. 🤦♀️ How can I fix that?
Could you send it again (`ngit send`) and send a screenshot of the CLI output?
When I do ngit init, what does the "name" field refer to? I thought it was my username, but is it the repo name?
I had to guess what the fields meant, when filling everything in, so now it looks like this and I think that's all wrong. https://nostrcheck.me/media/fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1/c4a4bcf9ec076b7ad9038a986832eed0e2b69c09600491c84cde0c5bff64af5a.webp
It should include a one sentence description of what the field means. Shouldn't it?
Everything other than identifier can be updated by running `ngit init` again
okay What do I have to put in the clone and website fields?
Clone is the URL of the git repository on a git sercer used for cloning and fetching the latest tip of the master branch. It defaulted to origin. Website is for the URL of the projects homepage / best URL to find out more about the project.
your events were successfully received by the relays. for some reason they are not being returned when queried by ngit or gitworkshop.dev. I manually queried the relay for your patch events and found them. so this link will work: https://gitworkshop.dev/repo/SilberWitch/proposal/5f21ee609ea743feafb9c13144c096c863f13592bbcf3912ece6b03875798511 I'll look at the issue of them not showing up on the gitworkshop.dev repo page and ngit first thing tomorrow.
I am tracking this issue through: nostr:nevent1qqs0uwwmd05tu6jqcjd55k5he6tvsxlu2xxstd3xnykr2504n3t2qvslvnhqc
oh nice, working on git stuff over nostr? The relays accept all kinds by default. There are settings to filter them just like with pubkeys if you wanted to do that.. (like to create a relay that only accepts git notes, or the opposite).
a relay plugin to enablr repo benefactors to pay a relay to accept events related to the relay would be cool
relay.tools can do this
How would it know if the event was related to the repo? All proposals and issues would tag the repo event but on these might not
The event looks like it is a force push (also know as new revision) of an existing proposal so it isn't displayed in proposal lists. The reference to the original proposal is actually a reference to a kind 1 event and there isn't an original proposal therefore it doesn't get displayed. This is a result of a bug in the latest vesion of ngit (v1.1.2) when running the command `ngit send` with the `--in-reply-to` flag. I'll close this issue. The bug in ngit list is tracked through: nostr:nevent1qqs0uwwmd05tu6jqcjd55k5he6tvsxlu2xxstd3xnykr2504n3t2qvslvnhqc https://gitworkshop.dev/repo/ngit/issue/fe39db6be8be6a40c49b4a5a97ce96c81bfc518d05b626992c3551f59c56a032
The event looks like it is a force push (also know as new revision) of an existing proposal so it isn't displayed by `ngit list`. The reference to the original proposal is actually a reference to a kind 1 event and there isn't an original proposal therefore it doesn't get displayed. The event was almost certainly created with `ngit send` with the `--in-reply-to` flag referencing the kind 1. `ngit send` does no checks to ensure `--in-reply-to` is actually a root proposal. This caused the error. This is a bug that should be fixed. The language 'in-reply-to' is super miss leading. It is used because it replicates the functionality of the `git send-email` 'in-reply-to'. There is a potential feature request here also. `--in-reply-to` should support referencing other events: kind 1s, issues, or even other things.
All it would need to do to fix the bug and add the feature would be to check whether the id is a proposal root and if not omit the 'revision-root' tag and potentially turn the 'reply' into a 'mention'.
@Laeserin do you remember if you used the '--in-reply-to' flag?
I did, yes. I am determined to break everything that can be broken, but by accident. 🙈
well your doing a good job so far. you used a pretty natural intuition on this one.
I was thinking it might be the basis of linking issues to different repos. Like, I accept support issues on gitcitadel and then somehow link them to an issue on a different repo.
yes, you should be able to tag a issue, comment, proposal or commit in proposal from a repository in a note (proposal, issue, comment) send to a different repository and have a reference to it and have it show up in both places. Similar how it works 'mentioned in' in github I suppose. this is dependent on this issue and: nostr:nevent1qqsg9fdqq7djq2sc7xamt49n7zd5qu73y8pupxfqxm3s76j3r25shqqhtk8jp https://gitworkshop.dev/repo/gitworkshop/issue/82a5a0079b202a18f1bbb5d4b3f09b4073d121c3c0992036e30f6a511aa90b80 and
do you think that would adequately address the need?
Yes! ☺️ Anything more complex and you'd need a cross-repo issues board, or something, which would be cool for multliple-repo projects, but I wouldn't work on that until we get the kinks worked out or you'll get drowned in change requests. Would probably need a change in the NIP to establish linked repos in an overarching project, or something. Dunno.
in ngit you can now tag as many issues, npubs or other nostr references as you want using the `in-reply-to` flag. in commit 10498b953d36304b441fcb162155c2487046206f. There is probably a feature request needed for gitworkshop to display these references nicely.
do you think that would adequately address the need?
Yes! ☺️ Anything more complex and you'd need a cross-repo issues board, or something, which would be cool for multliple-repo projects, but I wouldn't work on that until we get the kinks worked out or you'll get drowned in change requests. Would probably need a change in the NIP to establish linked repos in an overarching project, or something. Dunno.
in ngit you can now tag as many issues, npubs or other nostr references as you want using the `in-reply-to` flag. in commit 10498b953d36304b441fcb162155c2487046206f. There is probably a feature request needed for gitworkshop to display these references nicely.
Yes! ☺️ Anything more complex and you'd need a cross-repo issues board, or something, which would be cool for multliple-repo projects, but I wouldn't work on that until we get the kinks worked out or you'll get drowned in change requests. Would probably need a change in the NIP to establish linked repos in an overarching project, or something. Dunno.
in ngit you can now tag as many issues, npubs or other nostr references as you want using the `in-reply-to` flag. in commit 10498b953d36304b441fcb162155c2487046206f. There is probably a feature request needed for gitworkshop to display these references nicely.
