From 000003ba1b85708684a2fd2f7c1f4eee7de504dd Mon Sep 17 00:00:00 2001
Subject: [PATCH 0/49] gnostr-legit commit
gnostr-legit commit
Login to reply
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 demonstrated a git based "timechain" on #nostr with proof of work!
#gnostr
hope the test was useful...
#ngit #nostr #gnostr
i think also there was a forced push somewhere in the history... and maybe my repo has diverged - just a guess.
i know it is funky - i wont take it personal if you dont merge it - i can redo it. more of a test
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
i can add pow to the event id to add even more pow - big O
once i get that part of the protocol ironed out - we can add the git commit miner to #ngit
messing around with git blob construction for git+nostr
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.
Nah - it was just a test. Messing with other stuff
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.
