Merge remote-tracking branch 'origin/entomologist-data' into entomologist-data

This commit is contained in:
sigil-03 2025-07-19 00:20:58 -06:00
commit 3e416a997f
34 changed files with 70 additions and 2 deletions

View file

@ -0,0 +1 @@
2025-07-07T16:49:13-06:00

View file

@ -0,0 +1 @@
add get() and get_mut() API to database

View file

@ -0,0 +1 @@
db

View file

@ -0,0 +1 @@
2025-07-18T16:26:06.414392436-06:00

View file

@ -1 +1 @@
inprogress done

View file

@ -0,0 +1 @@
profile ent to determine where slowdowns occur

View file

@ -0,0 +1 @@
i think my preference is ↖ since it more concisely represents that this issue is waiting on other issues in the DAG / flow...

View file

@ -0,0 +1,8 @@
add dependency count to `ent list`
candidate emojis:
↖ - represents the "dependency tree" DAG edge that points to this issue
⌛- shows that the issue is waiting on something else
🔗- shows that the issue is linked to something else

View file

@ -0,0 +1 @@
filter issues with comment activity in a particular timeframe

View file

@ -1 +1,2 @@
tui
tui/v0.1 tui/v0.1

View file

@ -0,0 +1,3 @@
What do you mean by ent updating itself?
Do you mean it git clones itself and cargo builds and installs itself?

View file

@ -0,0 +1,3 @@
add `ent update`
allow `ent` to update itself when commanded to

View file

@ -0,0 +1 @@
2025-07-09T11:03:45-06:00

View file

@ -0,0 +1,15 @@
add a layer to the architecture with a DB api between the FS and ent?
This issue grew out of the discussion in issue
08f0d7ee7842c439382816d21ec1dea2.
Currently the entomologist crate code directly reads and writes files
and calls `git commit` when it wants. The directory is managed by the
application, generally as an ephemeral worktree containing a (possibly
detached) checkout of the `entomologist-data` branch.
We may be able to simplify the ent internals (and the application)
by adding a "database" API between ent and the filesystem.
There is some preliminary design brainstorming in the issue mentioned
above.

View file

@ -0,0 +1,9 @@
fix parse error in `ent done-time`
Got this error when i typoed the RFC 3339 time (missing `:` in timezone
offset):
$ ent done-time 8c73c9fd5bc4f551ee5069035ae6e866 2025-07-07T22:29:25-0600
thread 'main' panicked at src/bin/ent/main.rs:503:26:
called `Result::unwrap()` on an `Err` value: ParseError(Invalid)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

View file

@ -0,0 +1 @@
2025-07-11T20:32:23-06:00

View file

@ -0,0 +1 @@
sigil-03

View file

@ -0,0 +1 @@
had to update the file structure as well, but this is done, and up in !25

View file

@ -0,0 +1,3 @@
for now, let's just add the ability to mark dependencies, and then later we can build functionality on top of it which allows an application to decide what to do based on the state of those dependencies.
i think regardless we should always keep the dependencies, unless they get removed intentionally, and should instead operate off of the `state` of those dependencies.

View file

@ -0,0 +1 @@
inprogress

View file

@ -0,0 +1 @@
large ent repositories are slow

View file

@ -1 +1,2 @@
tui
tui/v0.1 tui/v0.1

View file

@ -0,0 +1 @@
2025-07-07T22:29:25-06:00

View file

@ -1 +1,2 @@
tui
tui/v0.1 tui/v0.1

View file

@ -1 +1,2 @@
tui
tui/v0.1 tui/v0.1

View file

@ -0,0 +1 @@
This issue duplicates 0f8b0c982bcfe7d5406bea58301014bc

View file

@ -0,0 +1 @@
teach `ent list FILTER` a new filter type that searches issue & comment descriptions

View file

@ -0,0 +1 @@
wontdo

View file

@ -0,0 +1,3 @@
add updates screen to TUI
updates pane will allow user to see all updates that occurred on a refresh (with a preview maybe?) and mark them as read

View file

@ -0,0 +1 @@
tui

View file

@ -1 +1,2 @@
tui
tui/v0.1 tui/v0.1

View file

@ -0,0 +1 @@
2025-07-18T16:22:31.222641244-06:00

View file

@ -1 +1 @@
inprogress done