Replies (17)

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
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.
i will be adding nip32/etc to the git commit miner #gnostr-legit - so it announces and pushes to a remote after mining :) #ngit #nostr #gnostr
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.