ATProto Browser

Record data

{
  "uri": "at://did:plc:hwevmowznbiukdf6uk5dwrrq/sh.tangled.repo.issue/3lkeinu32es22",
  "cid": "bafyreiao2wn6ov2i6xs3lmgeukbb2syjmpghykhsh7u74mqaiwmu4y4fui",
  "value": {
    "body": "As most of you probably know, we're working on a pull requests implementation for Tangled. The primary goal isn't to simply reimplement what GitHub has done for well over a decade—but to improve on the status quo, while making sure there's still familiarity to the whole flow. Keeping that in mind, we're introducing two kinds of pull requests.\n\n1. PRs v1 (patch requests)\n2. PRs v2 (submissions)\n\n## pull requests v1 (patch requests)\n\nThis is the first version of pull requests that we will launch. This follows a very simple model and serves to encourage smaller, \"driveby\" contributions. Here's how it would work:\n\n1. Clone the repository you'd like to contribute to.\n2. Make your change and commit it. You can do this on the main branch.\n3. Run `git format-patch -1 HEAD --stdout`. You may either pipe this to your clipboard program (pbcopy, wl-clip, ...) or simply copy the output from your terminal.\n4. Head to the repository on Tangled and create a new pull request from the \"pulls\" tab.\n5. Fill out your title and description of your change, and paste the `git format-patch` output in the provided textbox.\n6. Submit, and edit later as per review.\n\nOptionally, this can be extended to more than 1 commit (pass in `-2`, `-3`, and so on) and paste the resulting patch series into the textbox. This is of course, a *very* simple model that only facilitates smaller changes that can typically fit within a few small commits. However, we see this as a driver for contributions that probably would not have happened in the traditional flow simply due to the overhead involved.\n\n## pull requests v2 (submissions)\n\nThis workflow blends the more familiar GitHub PR model with changeset-oriented reviewing by allowing developers to work in feature branches and submit consolidated changes for review. This is what it would look like:\n\n1. **branch-based development**\n   * Developer creates and pushes to a feature branch as their working area\n   * Multiple incremental commits can be made during development\n2. **PR Submission**\n   * When ready for review, developer initiates a \"PR Submission\"\n   * System automatically squashes all branch commits into a single commit\n   * Developer is prompted to provide a title and detailed description (which becomes the commit message)\n3. **review process**\n   * Reviewers examine the consolidated changes in the submission\n   * Feedback is provided on the squashed commit\n4. **iteration**\n   * Developer makes additional changes to their feature branch based on feedback\n   * When changes are complete, they \"resubmit\" the PR, updating the commit message if necessary\n   * System creates a new squashed commit with updated changes, replacing the existing one.\n5. **finalization**\n   * Once approved, the squashed commit can be merged to the main branch\n\nThis approach maintains a clean history in the main branch while still allowing developers flexibility in their working branches.\n\n## meta notes\n\nThese changes heavily depend on knots supporting the new `/:did/:repo/merge` and `/:did/:repo/merge/check` endpoints. To identify whether a knot supports pull requests—and subsequent features like search, code navigation, … etc. in the future, we're planning to introduce a capability model.\n\nThis could look something like `knot.example.com/meta/capabiities` which returns a map of features and their versions. For instance:\n\n```\n{\n  \"pull_requests\": \"v2\",\n  \"code_search\": \"v1\",\n  \"foo_bar\": \"v3\",\n}\n```\n\nThis then allows the appview to conditionally enable operations and/or disable certain functionality on repositories hosted on knots that don't support them.",
    "repo": "at://did:plc:wshs7t2adsemcrrd4snkeqli/sh.tangled.repo/3liuighjy2h22",
    "$type": "sh.tangled.repo.issue",
    "owner": "did:plc:hwevmowznbiukdf6uk5dwrrq",
    "title": "proposal: pull requests",
    "issueId": 43
  }
}