| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Drop events. I'd still like to do them, but differently
* Start adding delete api stuff
* Set mailmap
* Delete delete delete
* Fix tests
* Make clippy happy
|
| |
|
|
|
|
|
| |
* Try to make clippy happy 🥺
* Fmt
* I missed one (can't run clippy locally on airport wifi...)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add automatic update checking
* Add setting to opt out of update checks
* Document options
* no
* no
* also no
* Make clippy happy
* Update atuin-client/src/settings.rs
Co-authored-by: Conrad Ludgate <conradludgate@gmail.com>
* fix features
Co-authored-by: Conrad Ludgate <conradludgate@gmail.com>
Co-authored-by: Conrad Ludgate <conrad.ludgate@truelayer.com>
|
| |
|
|
|
| |
* add some error messages
* fmt
|
| |
|
|
|
|
|
| |
* ignore JB IDEs
* tidy-up imports
* add rustfmt config
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* use feature flags
* fmt
* fix features
* update ci
* fmt
Co-authored-by: Ellie Huxtable <ellie@elliehuxtable.com>
|
| |
|
|
|
|
|
|
|
| |
* use bail macro
replace client database errors
remove dead code
* fix test
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The data part of the add history request is actually a string. I don't
want to introduce any structure here, and would rather keep it as "just
a blob". Even if that blob has structure secretly!
My fault for missing this in the last review
|
| |
|
|
|
| |
* make everything a cow
* fmt + clippy
|
| |
|
|
| |
Also allow unique listing and more ergonomic cwd usage
|
|
|
* Switch to Cargo workspaces
Breaking things into "client", "server" and "common" makes managing the
codebase much easier!
client - anything running on a user's machine for adding history
server - handles storing/syncing history and running a HTTP server
common - request/response API definitions, common utils, etc
* Update dockerfile
|
