README.md |
byr (try v2)
introductory references
- https://tom-vykes.medium.com/the-worst-things-about-github-8e8efc60fae3
- 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 child’s play (too many versions of branches)
- Undoing commits is a nightmare
- conclusion: monorepo, 2 branches (
main
vsstable
)
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
- unreviewed: not in main, active
- rejected/abandoned: not in main, inactive
- submitted is equal to {unreviewed or abandoned}
- unsubmitted