I'm definitely intend to add various features that involving getting data from git servers such as, browsing files, viewing commits, overlaying patch comments against code in the main branch tip

OOTB = Out Of The Box ie with default configuration, or at least without any custom code.

thanks for trying out ngit. How did you find the experience of advertising your repo and creating a proposal or two?

I'm trying to work out your intent here with the two proposal. was the second intended to be amendments to the first?

I notice under 'repository metadata' I can publish a repo event, issuing an ownership claim for your repository with a different name, is that intentional?

I also notice that you havn't yet issued one. Can you do so? I'd love to explore integrations with gitworkshop.dev. Some git server providers (annoyingly github), limit the interactions that a web client such as gitworkshop.dev can achieve that are possible with a standard OOTB with a git server.

I work on bitcoin adjacent freedom tech. https://gitworkshop.dev, ngit and https://metadata.nostr.com are 3 of my projects

I love it's minimalist look

I think most clients must factor this into their design and don't rely so much on waiting for a EOSE.

It should just timeout and move to the next step.

I don't have any integration tests built for this scenario.

Could it be that the EOSE event is not sent until after the timeout. I'm finding that its common for a least one relay to timeout but not consistently the same one.

Is bostr definately sending thr EOSE event?

Is the error reproducable? What would should I follow to do so?

Kudos for checking out the request to investigate why it might be failing.

I also get that feeling. should I really be able to be naughty and someone's issue on a project I don't maintain? I have considered restricting it to just 1) user who raised the issue and 2) repo maintainers (OPTION 1).

then I thought that complexity shouldn't be added to the protocol to solve potential problems that haven't manifested. this has to be traded-off against the adding to the protocol when other have started to implement it. This thread illustrates how this annoys developers and leads to partially implemented NIPs: nostr:nevent1qvzqqqqqqypzpms35h0lgrqe542lg8ly9dy0qrnp3jgjy43z4cmmds4mv7mkcnjfqyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgwwaehxw309ahx7uewd3hkctcqyrnw36q5thdufr0d5mqjp2cren2azqgs2hsrqhrfqdqrzcpftgxkcgwdc6x

So what is the problem with being able to change a status on an issue or proposal I didn't create on a repository I don't maintain? I think it is:

1) malicious actors who change statuses to create chaos (SPAM status events) - couldn't this be dealt with like other SPAM?

2) users who, operating in good faith, close or reopen an issue / proposal but don't understand the maintainers approach, or wider context around why this sort of issue / proposal should remain closed. perhaps there could be the option to add a 'locked' hashtag which means future status events from non-maintainers should be ignored (OPTION 2)?

Did it show a timeout from one of the relays after 10s whilst showing success from the others before moving on to complete the rest of the command?

The timeout is usually a failure to connect to the relay, or less likely, a failure to receive the EOSE event.

Yes. Maybe a tabbed view which starts on the 'Open' tab and other statuses could be selected via left and right arrow keys.

More simplistically, it could just show open proposals and accessing proposals with other statues could be achieved by providing its nevent in a command line parameter.

You have clearly put alot of thought and creative energy into it and its exciting to see. I'll take a proper look at it tomorrow when I can devote some attention to I.

your commit message is pretty intriguing . from the proposal cover letter I assume you created it with gnostr-legit. I'd love to find out more about what you are doing with gnostr.

thanks for the proposal. its a typo fix for the word 'download'.

ngit sent the 48 previous commits as part of the patch set. I think ngit did this because you hadn't pulled from origin into the 'main' branch but instead opted to pull directly into your feature branch. ngit currently assumes that commit not in the 'main' branch are part of the feature and includes them in the proposal. does that sound right?

perhaps ngit should check against 'origin/main' (or 'origin/master') instead. or it look for a remote with a url most similar to that in the repo event, and look for '[remote-name]/main'. that might be more robust.

it should also sense check the number of commits

perhaps it shouldn't make any assumptions and present a list of recent commits in the current branch for the user to choose from

did it fail to fetch your profile? was it the first time you used it (it was getting your profile for the first time)? was there an error message?

Yes!

Re point 2: You can submit the latest commit as a proposal with `ngit send HEAD~1`. Is that what you mean or do you want to store the entire repo as nostr events and not use a git server?

Its only fetching new profile events. The 'since' is the date of the, already processed profile event.

Have you found an issue of a bug? Is something not working for you?

I think that was a github UI clone with the intention of adding nostr intergration.

I could be misremembering but I think the creator is working on GitNestr