| Age | Commit message (Collapse) | Author |
|---|
|
Progress reporters were not being cleared after successful operations,
leaving progress bars visible in the terminal output. Now they are
properly cleared when all operations complete without errors.
|
|
Update push operations to use non-interactive mode by default, removing
prompts that would block automated git operations.
|
|
fix breaking changes
|
|
as its useful information
|
|
copy relay fetching approach to async and reporting
|
|
so it doesnt use the git_repo
|
|
so it shows a summary rather than a lot of lines of issues
|
|
also reduce the clutter in the cli output for grasp servers.
|
|
to ensure we dont try and fallback to ssh
|
|
update patches ahead of wider upgrade. clippy required some autofixes
|
|
only the maintainers and author of a poorly formatted proposal need
to know it was submitted but cant be created as a PR branch
|
|
fixes to change attempted in 4fc659074ec5ced3cc0727cf1f3e6af082a189cc
|
|
following its inclusion in the NIP-34 spec
|
|
move the PR push code in 'ngit send' into lib.
reuse the non-interactive fallbacks in git-remote-nostr
|
|
to align more closely with githubs `refs/pull/*/head`
we can pretend that pr means both Patch Request and Pull Request
|
|
even if it is not on repository remotes, as it may have been pushed
to a user's git server instead
|
|
abstracted git remote helper fetch functions
added support to `ngit list` to fetch PR data and checkout as proposal
branch
|
|
handle scenario when correct annotated tag is on a remote.
peel to tip commit doesnt give the correct oid so we must use the
annotated tag oid instead when comparing.
|
|
limit syncing to a single reference with this new parameter.
change instructions for out of sync remotes to use sync with this new
option.
|
|
This branch name cannot be attacked by brute forcing a
shorthand event id like refs/pr/<branch-name(<shorthand-event-id)
can.
|
|
here we can list Pull Requests whose data aren't on the repo relays
without causing `git clone nostr://` to fail.
we can also list proposals of all statuses so that can review
closed proposals.
|
|
we cannot list PRs under refs/heads/pr/* unless we are sure the oids
are accessable on a git server as it will cause `git clone` to fail.
we now only list PRs that are on accessable repo git servers under
refs/heads/pr/*.
we should be able to list them under under refs/pr/* as the clone
command only fetches refs in refs/heads so we will do this
seperately.
|
|
|
|
to make it's purpose clearer
|
|
allow specifying ref for pushing PR to custom clone url
|
|
if the repo doesnt list any grasp servers, or pushing to them fails
|
|
send as a PR if the commit would make patches that are too big for
nostr events.
send as a PR update if the proposal is PR.
send as a PR, revising a patch root, if patches would be too big.
in tests `get_pretend_proposal_root_event` has to be a actual proposal
with a tip, rather than just a cover letter, so we have replaced it.
|
|
for future use in `ngit send`
|
|
NIP-34 specifies patch revisions should have a `t` tag of
`root-revision` whereas we have been using `revision-root`.
this fixes it and and handles events created with the incorrect tag.
|
|
so that we can use it in `ngit send`
|
|
so we can use it in ngit as well as remote helper
|
|
required for rust-nostr v0.43 update
|
|
I have now replicated the issue discussed in the last commit by
overwriting my global git config item tag.gpgSign and setting
it back to false, which is default the default.
ngit was only supporting annotated tags and fiatjaf was pushing
a lightweight tag.
I'm confident that this will resolve the issue
|
|
fiatjaf reported panic:
```
<commit-id> can not be successfully peeled into a tag (git_object_t=4).
```
when making a tag and running `git push --tags`
I could not replicate but line it was coming from should use 'from'
rather than 'to'.
|
|
to enable forthcoming ngit sync cmd
|
|
to enable forthcoming `ngit sync` cmd
|
|
as these events use `c` instead of `commit`
|
|
for use by `ngit list`
|
|
as a temporary measure
|
|
when an upgrade to a pr is needed, dont also try and send patches
|
|
erorr if the pushed ref would produce a proposal with no patches, or
if the ref is in origin/<main-or-master>
|
|
when a patch is upgraded to a pr, eg because new commits would be
too large to be additional patches, the patch receives a closed
staus and the new pr 'e' tags the original root patch.
we therefore need to inherit the new pr's status instead of using
the closed status.
the closed status was used so that clients don't have to support
pr revisions of patches, and still have a good UX.
|
|
instead of status events from any pubkey
|
|
issue a pull request update if pushing or force pushing
a pull request
issue a pull request with an e tag for original patch and close status
for the original patch when pushing or force pushing against a patch
when the new commits are too big to be iussed as patches
|
|
to reflect there new role of also pushing prs to git severs
|
|
but only for new proposals
|
|
we try and get them from clone urls of repo and fallback to
those specified by contributor
|
|
remote will list the refs under `pr/*` namespace.
`ngit list` will display in the list of open / draft proposals.
it won't yet fetch the related oids to enable fetching or checking
out the branch.
|
|
to latest available and apply fmt fixes
|
|
to improve reliability
|
|
in function, params and variable names
|
|
includes a change to a git config itme name
|
|
in preparation for enforcing the inclusion of HEAD
|
|
based on jb55 trying to use this with damus
nostr:event1qvzqqqqqqypzqvhpsfmr23gwhv795lgjc8uw0v44z3pe4sg2vlh08k0an3wx3cj9qy88wumn8ghj7mn0wvhxcmmv9uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz7qpqec3c59c4yu4yrsa9fedu27rnygnemj2cfmumf6fw7385wfthg57slj72ux
|
|
as they are just noise
|
|
To ensure additional maintainers publish an annoucement event,
require it for them to push
|
|
we need to be careful with git servers with their own permissions so
a ngit user doesn't inadvertantly push changes on top of a another
user who pushed directly to the git server without using the
force flag.
We dont have this problem with ngit-relay so we can always force
push, even if the user didnt as nostr is the authority of state.
|
|
otherwise it tries all the protocols and reprots on each
|
|
via git config so they can be overwritten locally and globally
|
|
remove the code that guessed whether it was an authentication failure
and gave up is it wasn't. this prevents it from trying http for push
when ssh is not supported eg. ngit-relay
|
|
update nix dependancies to latest version using default update options
run `cargo clippy --fix` and `cargo fmt` to fix new clippy errors
|
|
resolving
nostr:note1qu8le4a8qz9hhxy6q85txejcq0kln0r3s9vdtwrhtqwvauc6nxuqn3fj0z
so it doesnt appear frozen when there are lots of events being signed
by a remote signer
|
|
when nostr and the gitserver are out of sync an error was thrown when
the git server was behind during soft push. It should only throw
the error if its ahead of the tip to be pushed.
|
|
and fix all of the breaking changes
|
|
show draft as well as open PRs as remote branches
|
|
improve reliability of getting current logged in user to assess if
they have submitted a proposal with the same name / branch name
|
|
improve clarity by renaming variables and methods
defend against `branch-name` tag with an unsafe name
|
|
simplify to allow the removal of warning:
`#[allow(clippy::too_many_arguments)]`
|
|
update the rust nightly `fmt` overlay which needs to be pinned
to a specific version (this case by date)
update formatting in main files via `cargo fmt`
|
|
update nix dependancies to latest version using default update options
fix warning related to idomatic patterns
|
|
comparing different versions of the nostr url string
|
|
as it was way too long
|
|
publish a merge event when the commit author signature and timestamp
match patches within an open proposal
|
|
allow any order of the commit ids
|
|
should alway list only the three-way merge commit id.
|
|
prevent a panic when tags are of an unexpect length
|
|
enable nostr git url format
alongside and
format
Merge branch 'pr/nip05-lez(ff1845c0)'
|
|
replace `NostrUrlDecoded::from_str` with
`NostrUrlDecoded::parse_and_resolve`
store nip05 pubkey mapping in git cache
|
|
get the latest user relay list before pushing patches and repo
announcement events
|
|
when a proposal was merged using fast-forward status rather than
by creating a three way merge commit.
if there are multiple revisions, the first one that contains merged
proposal tip will be referenced.
if there are multiple proposals that contain one of the commits,
they will all be marked as merged.
the nip needs to be updated as there is no single `merge-commit-id`
so that tag needs to support multiple values
|
|
previously fetch supported fetching multiple trusted coordinates at
once. The additional complexity trade off isn't worth it.
It will still fetch events related to the coordinates of maintainers
that the trusted maintainer lists.
A scenario where there might be multiple trusted coordinates is
where a large repo is split into multiple nostr repos to manage
pull requests and issues in seperate sub-units. I might therefore
have different remotes that target different identifiers.
There also might be different set of maintainers groups that are
have different views on the latest state of the same codebase and
they haven't split off into using different identifiers.
Its simplier ngit to fetch these different nostr repos independantly
when requested. git-remote-nostr will do this automatically as it
works through remotes but for ngit cmds a further change is required
so `get_repo_coordinates` and `try_and_get_repo_coordinates` prompts
to select the desired one.
|
|
as it was spelt with 1 'n'
|
|
fix error introduced in 6bcac672e04cb316de1f952c08b07937c7db3cc6
|
|
update the repo announcement event based on any updates to
maintainers.yaml that are included in commits pushed to
'main' or 'master'
|
|
use RelayUrl in repo_ref which I had resisted as it mutates relay
urls when printed to append a slash
|
|
and add `ngit init` to description / help content
|
|
to simplify and target users more than contributors and prioritise
building from source
|
|
in nearly all cases 'cannot' was used when an action was tried and
failed. 'failed to' is strictly better because:
* just because the action didn't work that time doesnt mean it
cannot work
* it is better at drawing the users attention to a problem
|
|
* simplify login menu, making it more accessable to newcomers and
easier to select remote signer options
* enable `ngit login` to work from anywhere (not just a git repo)
* assume fresh login details saved to global git config but fallback
to local repository
* maintain local repository login via `ngit login --local`
* maintain login via CLI arguments eg `ngit send --nsec nsec123`
* nudge users to remember nsec when pasting in ncryptsec for a
better UX, whilst maintaining the option to be prompted for
password everytime
* create placeholder menu items for help menu and create account
|
|
bump all rust-nostr packages to latest issued version.
there have been some breaking changes to nip46 and this applies
these changes.
|
|
instead of printing an error when `git-remote-nostr` is called
directly instead of via plugin, provide some guidance
|
|
when multiple maintainers enable opting out of storing state on nostr
this prevents other maintainers from pushing a state to the
git server which nostr servers wouldnt see because they are using the
nostr state.
|
|
currently the prefix is missed when listing refs after pushing a pr
|
|
bump all rust-nostr packages
|
|
if login details are known, log in straight away and respond to auth requests.
users can make a choice whether to sign these using their nip46 signer
|
|
or nostrconnect url string which is a much better UX flow for nip46
|
|
originally this was disabled because there was a concern that it
would effect the operation of the remote helper due as it prints
to stdout.
it now only writes to stderr.
|
|
make poorly formatted patches fail silently. we stop trusting that the
`commit` tag in the latest patch can be produced by apply the patches.
to achieve this we must recreate the commit during the list command,
which require fetching the parent oids.
support patches without optional `commit` and `parent-commit` tags.
|
|
to both tell users where events have been sent / failed to be sent
and to provide a status update so the user doesn't think its crashed
|
|
so it clear which patch is causing issues and it continues to report
the fetch problem to the git client.
we need a better solution it degrades gracefully rather than
stopping the operation.
perhaps list needs to only list PRs which it can create from existing
data objects?
perhaps list also needs fetch objects before fetch is called?
|