What’s in there

297 commits

39 merge-commits / 258 non-merge commits

306 files changed

4845 insertions(+), 5334 deletions(-)

Some more statistics about the codebase (thank you, tokei), because why not:

------------------------------------------------------------------------------- Language Files Lines Code Comments Blanks ------------------------------------------------------------------------------- BASH 8 151 96 17 38 CSS 1 27 24 0 3 Makefile 1 161 97 29 35 Markdown 99 4814 4814 0 0 Nix 2 98 66 11 21 Rust 258 33292 21849 6320 5123 Shell 14 519 280 157 82 TOML 60 3134 2104 422 608 ------------------------------------------------------------------------------- Total 443 42196 29330 6956 5910 -------------------------------------------------------------------------------

What changed

This release is rather small in number of changes, but rather big in impact of changes and complexity of the introduced changes. For a complete list of changes, have a look at the CHANGELOG file in the repository.

The filesystem backend was optimized so that imag does not keep the handles to the opened files, but reads the files in one go and then drops the filedescriptors. This way it is possible to read a large number of files with imag without running into filedescriptor limits.

The Store::entries() function interface was changed and now gives you an iterator which can be optimized to iterate only over subsets of imag entries. This speeds up several operations.

function interface was changed and now gives you an iterator which can be optimized to iterate only over subsets of imag entries. This speeds up several operations. imag now uses a uniform IO system where the runtime library automatically detects pipes and handels them accordingly to our standard behaviour. With this, command-chaining (piping like with normal shell commands) is possible, because if imag detects a pipe in the output, it automatically reports “touched” store entries. For example, imag ids | cat automatically prints the output of imag ids on stderr and the “touched entries” to the pipe. These can then be re-used, for example for another imag command or for something else. Example: Tagging some entries, by interactively selecting them with fzf : imag ids | fzf -m | imag tag add "foobar" .

automatically prints the output of on stderr and the “touched entries” to the pipe. These can then be re-used, for example for another imag command or for something else. Example: Tagging some entries, by interactively selecting them with : . imag now uses failure for error handling.

for error handling. imag-diagnostics got a progress bar.

Of course there were also a large number of fixes, updates of dependencies and other patches. For a even more detailed list, see the git history.

What’s coming

Lets have a look into the future, what will happen until the next release?

Workflow changes

As we moved away from github, the workflow will now change a bit.

The most important bit: This is only my workflow, things do not change for contributors! First of all, minor patches and fixups will not be merged “non-fast-forward” anymore. I will push “minor” changes to branches on github (usually the “minor” branch or some “fix-*” branch) to CI-test them, but if they succeed, I will fast-forward merge them into master from now on. This only applies to patches where one patch is the whole change and does not relate to other patches. So feature branches and multi-patch changes will still be merged with --no-ff . We tried to use git notes for keeping the changelog. Unfortunately, it proofed too clumsy. From 0.9.0 onwards, we will keep the changelog via the merge commit message, so the changelog will be gernerated using a new script which does: List there major changes with git log --merges --first-parent <latest-release>..master and the minor changes and fixes with git log --no-merges --first-parent <latest-release>..master .

What will be in imag 0.10.0

imag 0.10.0 will be a tooling release. imag-calendar and imag-mail will be written and added in imag 0.10.0. libimagentryref has to be reimplemented for that, which makes it another requirement for the release. But that’s it - I’m trying to keep the 0.10.0 release small. Maybe I opt to release it with only one of the tools ( imag-calendar / imag-mail ), depending on how fast we get there.

When will that be? Well, as I’m back on the road (traveling) until mid-february 2019, the release won’t be this year. It will definitively be next year, … when it is ready! :-)

Back to posts