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 ` if the original proposal was created on the master branch

Reply to this note

Please Login to reply.

Discussion

Maybe the details just aren't important.

With nostr you don't need a fork. Just clone a repository listed on nostr and send a PR right from your local git repository with`ngit send`.

as users who have used ngit to create proposals / repo events and interact with them on gitworkshop.dev, what level of information would have helped you grok what you need to grok?

nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z nostr:npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg nostr:npub1896p07z8xngpct5ma00mdrad4gqfnwfwdqcl706wrm25ajynahhs27x5ge

Would calling proposals PRs help? How can we communicate the enduring need for a source git repo but not forks?

Thanks for that explanation Dan.

I noticed in all flows you referred to them as pull requests, despite the differences. What about using this familiar terminology and not changing it, but when the user first interacts with a PR, we explain to them how it's different from Github, in as few words as possible.

Maybe "Fast PR", let's add the value to the name.

Or also simply "Nostr PR", this add promote the brand and the underlying tech, keeping the original function labeling.

PR is familiar terminology for GitHub users but I'd just call them patches, that's what they are after all. Patch is a well understood technical term in code collaboration.

Make sense, I like this

PPs , Patch Proposals. easy to type .

PRs make sense for github as a centralize model (top-down) with git hub as single reference ( relative to central ), ngit is like git ( bottom - up ) and have local repository as reference, but is expose as patch ( relative to local ).

if this is done in ngit the term is patch, I think, but in gitworkshop is just a proposal until merged, the term is also PR ( PP ) ( github is centralized, patch is PR, allready deployed )

Don't think renaming proposals would help. It's a different workflow and a different mindset.