I was thinking it would be best to start with vscode. Vim users would likely be more comfortable using ngit than the average vscode user.
I have considered plugins for IDEs to make it easier for users who don't use the command line so much or users who want to view proposal comments directly from the IDE. what do you think?
what sort of features would you want from a desktop application that differ from the web version?
thanks for the feedback. do you think standard social nostr clients should always these git notifications?
perhaps they should display the notifications but keep them off the main feed?
an alternative path, or perhaps, would be to add a feature to gitworkshop.dev to allow users to selectively boost a message but including a reference to it in a standard kind 1 message that social clients display on the main feed. is that what you had in mind when you raised the issue?
here is the situation today:
project maintainer(s) get notifications of new proposals and issues only in Amethyst out of the clients tested.
in some clients (coracle, snort,and nostrudel) maintainers and item authors get some reply notifications: the kind 1 type that gitworkshop.dev produce, but not the specialised kind that Amethyst produce.
in still other clients (primal) there are no notifications.
in the just released ngit v1.1.1 `send` doesn't assume the commits to include in the proposal but presents a multi-select, defaulting to the likely commits.
These likely commits now now taken from a comparison of the current branch with 'origin/master' or 'origin/main' falling back to 'master' or 'main'.
Thanks for discovering this commit selection issue to help iron our some of the hard edges in ngit.
Free is the person who finds liberation their constraints
at the point this proposal was created, sjors hadn't pushed the proposal's parents commit to origin. Therefore I cannot view i cannot check it out as a branch in ngit and `git am` will not apply it, although i can download it.
I am soon to release a prompt in ngit that asks users if they are sure they want to produce a proposal like this.
My eyes weren't deceiving me. Intermittently, workshop.dev appears to render the first commit again where the second commit should be in the thread. This is a bug that needs exploring future.
Ignore this. my eyes are deceiving me. The commit id are not the same and the diff is different. this was a successful test of `ngit push`!
This commit has been double posted against the same proposal in events with a timestamp a few minutes apart. This is clearly a bug.
Did you run the `ngit push` command? Could it be that you were trying this out and it didn't pick up the existence commit event?
Thanks for the encouragement. I might add `ngit clone nevent/identifier` to make it easier to clone projects without having to understand this distinction. ultimately I would like to create a git remote-helper for so users can do `git clone nostr@nevent...` or `git clone nostr@repo-identifier`. That way maintainers could swap out git_servers without the users having to take any action.
nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn and nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 are a really entertaining double act. They have a really similar awkward humour that works really well together. I love the slightly longer that normal moment of silence they leave between each others comments.
I immediately regret posting this because I'm busy with another project right now and I can't think of any other situation where the solution would be useful.
I thought of a potentially better way of managing nips, with less central control, where its easier to follow updates and understand which standards (nips/nip version) clients are following.
