DanConwayDev on Nostr: Sorry for the long answer. I clearly need help in finding a clearer way of explaing ...
Sorry for the long answer. I clearly need help in finding a clearer way of explaing how it works.
In the github flow a contributor needs to:
1) clone the source repository
2) make changes as one or more commits on any branch
3) host a fork of the repository
4) push their local branch with changes
5) create a PR - a request that the maintainers 'pulls' the changes from that branch into a named branch within the source repository
If during the discussion they want to make changes they typically
6) push additional commits to their fork implementing feedback
When the maintainer is ready to accept the changes they press the big green 'Merge' button and github creates a merge commit in the source repository or squashes the change into a single commit and adds it to the source repoistory.
In the patches over email flow a contributor needs to:
1) clone the source repository
2) make changes as one or more commits on any branch
3) get setup with an email client that can deal with patches over email
4) signup to the mailing list for the repository, or area of the repository they are interested in
5) send the changes a patch (or a patch set)
6) any requirements to improve the changes before they are accepted are done by issuing a new patch set 'revision'. The existing commits are modified to incorporate changes and the whole patch set is sent again. its never the case that only the required updates are sent as additional patches.
The maintainer 'applies' the patch(set) to the latest master branch, dealing with any merge conflicts at the point of review, and either chooses to push these changes to the source repo or reset their local branch and send feedback via email.
more info at https://git-send-email.io
nip34 tries to support both flows. In nip34 patches (or patchsets) are wrapped in a nostr events along with some extra data so the change can be created fully as a local branch. This way they can act as patches (although some might not like that updates can be tacked-on as extra commits) and PRs (although there is no fork).
1) clone the source repository
2) make changes as one or more commits on any branch
3) install ngit and create / sign in with nostr keys
4) send the proposal
5) any requirement to improve can be done by adding additional commits with `nigt push` or update the entire proposal with by updateding existing commits and running `ngit push --force` (issuing a new revision) or `ngit send --in-reply-to <original proposal nevent>` if the original proposal was created on the master branch
In the github flow a contributor needs to:
1) clone the source repository
2) make changes as one or more commits on any branch
3) host a fork of the repository
4) push their local branch with changes
5) create a PR - a request that the maintainers 'pulls' the changes from that branch into a named branch within the source repository
If during the discussion they want to make changes they typically
6) push additional commits to their fork implementing feedback
When the maintainer is ready to accept the changes they press the big green 'Merge' button and github creates a merge commit in the source repository or squashes the change into a single commit and adds it to the source repoistory.
In the patches over email flow a contributor needs to:
1) clone the source repository
2) make changes as one or more commits on any branch
3) get setup with an email client that can deal with patches over email
4) signup to the mailing list for the repository, or area of the repository they are interested in
5) send the changes a patch (or a patch set)
6) any requirements to improve the changes before they are accepted are done by issuing a new patch set 'revision'. The existing commits are modified to incorporate changes and the whole patch set is sent again. its never the case that only the required updates are sent as additional patches.
The maintainer 'applies' the patch(set) to the latest master branch, dealing with any merge conflicts at the point of review, and either chooses to push these changes to the source repo or reset their local branch and send feedback via email.
more info at https://git-send-email.io
nip34 tries to support both flows. In nip34 patches (or patchsets) are wrapped in a nostr events along with some extra data so the change can be created fully as a local branch. This way they can act as patches (although some might not like that updates can be tacked-on as extra commits) and PRs (although there is no fork).
1) clone the source repository
2) make changes as one or more commits on any branch
3) install ngit and create / sign in with nostr keys
4) send the proposal
5) any requirement to improve can be done by adding additional commits with `nigt push` or update the entire proposal with by updateding existing commits and running `ngit push --force` (issuing a new revision) or `ngit send --in-reply-to <original proposal nevent>` if the original proposal was created on the master branch