Unified · Split
| @@ -243,11 +243,17 @@ Provide a CLI to for the most basic user journey: · 242 unmodified lines | ||
| 243 | 243 | as well. What would an MVP look like? Maybe even something that could ship with gitoxide. |
| 244 | 244 | * [ ] A truly awesome history rewriter which makes it easy to understand what happened while avoiding all pitfalls. Think BFG, but more awesome, if that's possible. |
| 245 | 245 | * [ ] `git-tui` should learn a lot from [fossil-scm] regarding the presentation of data. Maybe [this](https://github.com/Lutetium-Vanadium/requestty/) can be used for prompts. Probably [magit] has a lot to offer, too. |
| 246 | −* [ ] Can markdown be used as database so issue-trackers along with meta-data could just be markdown files which are mostly human-editable? Could user interfaces | |
| 247 | − be meta-data aware and just hide the meta-data chunks which are now editable in the GUI itself? Doing this would make conflicts easier to resolve than an `sqlite` | |
| 248 | − database. | |
| 249 | − * ~~A git-backend for `sqlite` which should allow embedding sqlite databases into git repositories, which in turn can be used for bug-trackers, wikis or other | |
| 250 | − features, making for a fully distributed github like experience, maybe.~~ | |
| 246 | +* An event-based database that uses commit messages to store deltas, while occasionally aggregating the actual state in a tree. Of course it's distributed by nature, allowing | |
| 247 | + people to work offline. | |
| 248 | + - It's abstracted to completely hide the actual data model behind it, allowing for all kinds of things to be implemented on top. | |
| 249 | + - Commits probably need a nanosecond component for the timestamp, which can be added via custom header field. | |
| 250 | + - having recording all changes allows for perfect merging, both on the client or on the server, while keeping a natural audit log which makes it useful for mission critical | |
| 251 | + databases in business. | |
| 252 | + * Can markdown be used as database so issue-trackers along with meta-data could just be markdown files which are mostly human-editable? Could user interfaces | |
| 253 | + be meta-data aware and just hide the meta-data chunks which are now editable in the GUI itself? Doing this would make conflicts easier to resolve than an `sqlite` | |
| 254 | + database. | |
| 255 | + * ~~A git-backend for `sqlite` which should allow embedding sqlite databases into git repositories, which in turn can be used for bug-trackers, wikis or other | |
| 256 | + features, making for a fully distributed github like experience, maybe.~~ | |
| 251 | 257 | |
| 252 | 258 | ### Ideas for Spin-Offs |
| 253 | 259 | |