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
Login to reply
Replies (3)
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.
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.