Research nodes in development regarding version control systems
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Alain Zscheile 7a6cab0b70
patch states: +frozen
1 month ago patch states: +frozen 1 month ago

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

byr (try v2)

introductory references

    • Log spam
    • Pull Requests and Merging is language is absurdly confusing
    • Feature branches are totally flawed and cause work in isolation
    • The “advantage” of working offline is.. frankly stupid
    • Unstaged, Staged, Commit
    • Working on multiple projects requires multiple clones
    • Remote vs. Local Repository makes time travel look like childs play (too many versions of branches)
    • Undoing commits is a nightmare
    • conclusion: monorepo, 2 branches (main vs stable)

features wanted on server side

  • monorepo, with a main branch and others which are all cherry-picked from that (a full fork is necessary to deviate); restriction to just subsequences is good. (avoid accidental deviation)
  • snapshots (compressed "checkouts" basically, to avoid having to replay all of history on any complex actions) and patches (scripts, run in sandbox)
  • hooks, e.g. post-patch
  • patches can be in multiple states:
    • "applied" (contained in main)
    • "unreviewed" (not in main, active)
    • "rejected/abandoned" (not in main, inactive)

features wanted on client side

  • patches can be in multiple states:
    • "applied" (as above)
    • "submitted" (pushed to server, but not applied)
    • "unsubmitted" (not pushed to server)
  • local tree can be in multiple states: "commited", "uncommited" (current state is not completely recorded in a commit)
  • no staging area, but using multiple trees should be easy
  • no "untracked" data, enforce proper use of .ignore files

resulting design

patch states

  • applied: contained in main, frozen
  • unreviewed: not in main, active
  • rejected/abandoned: not in main, inactive
  • submitted is equal to {unreviewed or abandoned}
  • unsubmitted

Patches can be frozen (when they are a linked to a single snapshot), or be not-frozen (when they are linked to a command which gets automatically rebased)

enum PatchAct {

enum PatchInject {

struct PatchState {
    inj: PatchInject,
    act: PatchAct,

CLI user interface

reviewed changes all have two identifiers: their publishing (-> "unreviewed") revision (pub#[0-9]+) and the position in main, main#[0-9]+; there also exist local changes (local#[0-9]+). exclusion only based upon stuff in branch; inclusion only based upon publishing revision. A change belongs to a single server.

it is possible to define pre-diff hooks (e.g. auto-format all code) and post-apply hooks (e.g. run CI)

// user-local "remote" registration
// maybe use workspaces?
$ byr remote add [--dup=full|latest] $RNAME $URL
[$ byr remote set [--dup=full|latest] $RNAME]

// pulls data from remoe explicitly,
// should be usually unnecessary
$ byr fetch [$RNAME]

// removes the content of $DIR and replaces it with the current content of $BRANCH

// applies a patch script to a checkout, recording that in a change
$ byr a[pply] -m "change description" -s $PATCH_SCRIPT

// translates the current change into a diff, recording that in a change
$ byr a[pply] -m "change description" --diff

// upload newer changes to $RNAME
$ byr pub[lish] $RNAME

// mark a change as private to prevent it from being pushed to any server
$ byr private $CHANGE_ID