diff --git a/src/lib/components/Navbar.svelte b/src/lib/components/Navbar.svelte index d52b2c3..109e08d 100644 --- a/src/lib/components/Navbar.svelte +++ b/src/lib/components/Navbar.svelte @@ -12,7 +12,9 @@
-
+
+ About +
git

- pairs with ngit cli + pairs with ngit

@@ -59,7 +59,7 @@ install ngit
- learn more + learn more
diff --git a/src/routes/about/+page.svelte b/src/routes/about/+page.svelte new file mode 100644 index 0000000..a4cfdc6 --- /dev/null +++ b/src/routes/about/+page.svelte @@ -0,0 +1,292 @@ + + + +
+

About

+

+ gitworkshop.dev and ngit are tools to enable code + collaboration over nostr created and maintained by + DanConwayDev +

+

+ they implement the nip34 draft, which ports the git-email-patch model to nostr, and also have backwards compatible enhancements (nip34+ for shorthand) + eg. to optionally enable experiences similar to github PRs +

+ +

+ should we focus on improving the PR-like experiences or remove them in + favor of traditional patch-model patch application? please let use know! +

+

The Need

+ +

+ git is decentralized version control system, yet most freedom tech + projects use centralized walled gardens on top of git as a social and + collaboration layer for code changes +

+ +

+ by far the most popular, Microsoft's GitHub, has a history of banning + accounts and repositories without warning and this creates a real risk of + disruption for important projects like bitcoin-core +

+ +

+ whilst alternatives do exist, nearly all of them involve moving to an + another walled garden, either controlled by a different centralized + guardian, or self-hosted which is less suitable for a anarchic project +

+

+ some projects use patches-over-email: an alternative and decentralized + approach that pre-dates GitHub. despite its antiquated tooling, it has a + very smooth and effective workflow for those that use it regularly and has + proven to scale to very large projects like the linux kernal. +

+ +

+ ultimately, GitHub remains by far the most popular choice for freedom tech + projects. The accessible UX, convenience, inter-connected tooling and + network effect are just a few of the reasons +

+ +

The Opportunity

+ +

+ nostr is the ideal permissionless, decentralized and censorship resistant + social layer for the anarchic FOSS code collaboration use case. +

+ +

+ patch-over-email, with its proven scalability, lays the foundation for + providing this social layer without having to re-invent the complexities + of creating an efficient alternative to git server over nostr, or use + specialized relays. +

+ +

+ there is an opportunity to build modern tooling that compete from a UX + perspective and have the additional benefit of integrating into a wider + social ecosystem. +

+ +

The Philosophy

+ +

there is innovation happening with git and nostr in a few places

+ +

the philosophy of ngit and gitworkshop.dev can be summed up as:

+
    +
  • let git be git - don't try and reinvent git
    • +
  • + let nostr be nostr - leverage the benefits of nostr +
    • +
  • + learn from the success of others - eg. the PR model has + proved to be very popular. how can we enable similar experiences with patches? +
    • +
+ +

The Protocol

+ +

+ nip34 is draft nip (nostr protocol) for sending git patches + over nostr, similar to how patches are sent via email using `git format-patch` + and `git send-email`. The patches-over-email model has proven to be a robust + workflow that is used extensively; including in very large project such as + the linux kernel +

+ +

+ ngit and gitworkshop.dev are experimenting with some additional, backwards + compatible features (nip34+ for shorthand), some of which + may make it into the nip34 specification: +

+ +
    +
  • + patches optionally managed as branches, similar to GitHub PRs +
      +
    • + amendments to a proposal can be made by pushing a commit using ngit push + rather than issuing a complete revision, which modifies the original + commits (still possible with + ngit push --force + or + ngit send --in-reply-to nevent123...) +
      • +
    • + proposal can be checked out as a branch which reflects the repo + state when the proposal was generated with pgp signatures intact +
        +
      • + there is less friction for reviewers with this model as they + don't have to deal with resolving conflicts as patches are + applied to the tip of the main branch. whereas maintainers, who + might be considering accepting the proposal right away, may find + it preferable to resolves conflicts as part of their review +
        • +
      +
      • +
    • author pgp signatures and original commit_ids can be retained
      • +
    • + features can be 'merged' using a 'merge commit' so that a series of + feature commits can remain distinct rather than each applied to the + main branch directly. +
      • +
    +
    • +
  • + multiple maintainers for a repository and a pathway to smoothly + transition maintainership when a maintainer moves on +
    • +
  • + ensure that user who have already cloned the repository dont get scammed + by someone else issuing a repository event, pretending to be the + maintainer, and directing users to a malicious git server +
      +
    • + ngit init + creates an optional + maintainers.yaml file + in the root of your repo that lists the authorized maintainers and + desired relays +
        +
      • + a fallback is used to prevent contributors from needing to know + the event id if a maintainer is not ready to add a nostr + specific file to the repository. ngit tags the earliest unique + commit id in the repo event. ngit defaults to uses the most + recent repo event it finds with this tag. it also tags all + proposals with this id and when listing patches, also includes + patches sent to other repo events with this id as it is clearly + intended for the same repo. +
        • +
      +
      • +
    +
    • +
+ +

FAQs

+ +

+ Your not replacing GitHub, your still using it GitHub as a git server. +

+

+ it is trivial to switch git servers as they all operate the exact same + protocol. changing the social layer requires a social and UX shift which + can be challenging, disruptive and timeconsuming. +

+ +

are you trying to replicate / replace Github?

+ +

+ no. GitHub is a very large product with a lot of features which don't meet + the goal of freedom tech code collaboration. +

+

+ we are specifically looking to address the needs of anarchic FOSS freedom + tech products +

+ +

Enhancements

+ +

+ got ideas? please share them and lets explore as a community. here's three + to get you started: +

+
    +
  • DVM to run CI pipelines? yes please
    • +
  • + services to enable merge directly from nostr events. hello! +
    • +
  • + repo event showing authoritive tip of main branch and referencing + multiple git_server mirros? Hell yeah! +
    • +
+ + +
+ diff --git a/src/routes/ngit/+page.svelte b/src/routes/ngit/+page.svelte index 28e4312..771b21f 100644 --- a/src/routes/ngit/+page.svelte +++ b/src/routes/ngit/+page.svelte @@ -6,17 +6,54 @@

ngit

a command-line tool to send and review patches via nostr

-

- works seemlessly with gitworkshop.dev -

+
    +
  • + works seemlessly with gitworkshop.dev + +
    • +
  • fully compatable with nip34 draft
    • +
  • + enables proposals to be managed as branches, similar to GitHub PRs via + nip34+ +
    • +
+

ngit and gitworkshop.dev are new, experimental and in an alpha state.

+

Install

-

- until the release of v1.0.0 you will need to clone ngit-cli `main` branch - and build from source -

-
+

add the following binary to a directory from which it can be run globally: @@ -33,7 +70,8 @@ Windows TODO: issue v1.0.0 and activate these links + > + v1.0.0

@@ -43,7 +81,7 @@

Commands

-

run from the directory of the git repository:

+

run from the your product's git repository:

ngit init fetch and apply new proposal commits / revisions linked to branch

-

Learn More

+

Protocol

+

+ nip34 is draft nip (nostr protocol) for sending git patches + over nostr, similar to how patches are sent via email which is a model used + extensively including in very large project such as the linux kernel +

+

+ nip34+ adds backwards compatable features to nip34, primarily + to enable: +

+
    +
  • + patches managed as branches, similar to GitHub PRs +
      +
    • + maintain commit ids, pgp signed commits, enabling merge with commits + pgp signed by the author, amend commits +
      • +
    +
    • +
  • + multiple maintainers for a repository and a pathway to smoothly + transition maintainership when a maintainer moves on +
    • +
  • + ensure that user who have already cloned the repository dont get scammed + by someone else issuing a repository event, pretending to be the + maintainer, and directing users to a malicious git server +
      +
    • + ngit init + creates an optional + maintainers.yaml file + in the root of your repo that lists the authorised maintainers and desired + relays. +
      • +
    +
    • +
+

+ if feedback is possive on nip34+ features, they may make it into the nip34 + specification +

- ngit init - also creates an optional - maintainers.yaml file in the - root of your repo that lists maintainers and relays. If commited it will make - it smoother for contributors to find your repository event and also makes any - future transfer of repository ownership easier. + learn more