| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
I'd like to tidy up the root a little, and it's nice to have all the
rust crates in one place
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Imagine the scenario where a sync fails. The function touched here will
never save the sync time.
That means that external to this function, the sync never happened. The
next command will try and start one immediately.
The happy scenario is that this succeeds. The unhappy scenario is that
this fails. Fails, and isn't saved, so we try again...
Should add proper backoff but this is a good start.
|
| | |
|
| |
|
|
|
| |
* clear history id
* fix nu
|
| | |
|
| |
|
|
|
| |
* fix #1236
* lints
|
| |
|
|
|
|
|
|
|
| |
* Add connect timeout and overall timeout
* Make it configurable
* Fix test
* Add docs
|
| |
|
|
|
|
|
|
|
| |
* replace chrono with time
* Fix test chrono usage
---------
Co-authored-by: Ellie Huxtable <ellie@elliehuxtable.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
* Allow server configured page size
* Backwards compat via semver checks
* Correct header name
|
| |
|
|
| |
This can occur if history has been added + then deleted on a machine
before it has a chance to be synced to a new one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Delete all instances of a command
Our search command will de-dupe results by default. But... This isn't
great for deleting! You don't want to run it over-and-over-and-over
until all commands are deleted.
Loop the query, and keep on deleting what it returns until they are all
gone.
* Optimize delete upload
It was running a request for every element, on every sync lol
Only push a delete if needed
Future: push all deletes in one request
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add event data structures
This adds the data structures required to start syncing events, rather
than syncing history directly.
Adjust event
Fix
Add event data structure to client
* Add server event table sql
* Add client event table migration
Adjust migration
* Insert into event table from client
* Add event merge function
Right now this just ensures we have the right amount of events given the
history we have
BUT it will also be used to merge CREATE/DELETE events, resulting in
history being deleted :)
* Make CI happy
* Adjust
* we don't limit history length any more
* Update atuin-client/src/database.rs
Co-authored-by: Conrad Ludgate <conradludgate@gmail.com>
* fix usage
* Fix typo
* New Rust, new clippy stuff
Co-authored-by: Conrad Ludgate <conradludgate@gmail.com>
|
| | |
|
| |
|
|
|
|
|
| |
* ignore JB IDEs
* tidy-up imports
* add rustfmt config
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Begin moving to sqlx for local too
* Stupid scanners should just have a nice cup of tea
Random internet shit searching for /.env or whatever
* Remove diesel and rusqlite fully
|
| |
|
|
| |
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
|
