tkellogg/dura

You shouldn't ever lose your work if you're using Git

Dura

Dura is a background process that watches your Git repositories and commits your uncommitted changes without impacting HEAD, the current branch, or the Git index (staged files). If you ever get into an "oh snap!" situation where you think you just lost days of work, checkout a dura branch and recover.

Without dura, you use Ctrl-Z in your editor to get back to a good state. That's so 2021. Computers crash and Ctrl-Z only works on files independently. Dura snapshots changes across the entire repository as-you-go, so you can revert to "4 hours ago" instead of "hit Ctrl-Z like 40 times or whatever". Finally, some sanity.

How to use

Run it in the background:

$ dura serve &

The serve can happen in any directory. The & is Unix shell syntax to run the process in the background, meaning that you can start dura and then keep using the same terminal window while dura keeps running. You could also run dura serve in a window that you keep open.

Let dura know which repositories to watch:

$ cd some/git/repo
$ dura watch

Right now, you have to cd into each repo that you want to watch, one at a time.

If you have thoughts on how to do this better, share them here. Until that's sorted, you can run something like find ~ -type d -name .git -prune | xargs -I= sh -c "cd =/..; dura watch" to get started on your existing repos.

Make some changes. No need to commit or even stage them. Use any Git tool to see the dura branches:

$ git log --all

dura produces a branch for every real commit you make and makes commits to that branch without impacting your working copy. You keep using Git exactly as you did before.

Let dura know that it should stop running in the background with the kill command.

$ dura kill

The kill can happen in any directory. It indicates to the serve process that it should exit if there is a serve process running.

How to recover

The dura branch that's tracking your current uncommitted changes looks like dura/f4a88e5ea0f1f7492845f7021ae82db70f14c725. In $SHELL, you can get the branch name via:

$ echo "dura/$(git rev-parse HEAD)"

Use git log or tig to figure out which commit you want to rollback to. Copy the hash and then run something like

# Or, if you don't trust dura yet, `git stash`
$ git reset HEAD --hard
# get the changes into your working directory
$ git checkout $THE_HASH
# last few commands reset HEAD back to master but with changes uncommitted
$ git checkout -b temp-branch
$ git reset master
$ git checkout master
$ git branch -D temp-branch

If you're interested in improving this experience, collaborate here.

Install

Cargo Install

1. Install Cargo
2. If you want run release version, type cargo install dura else type cargo install --git https://github.com/tkellogg/dura

By Source

1. Install Rust (e.g., brew install rustup && brew install rust)
2. Clone this repository (e.g., git clone https://github.com/tkellogg/dura.git)
3. Navigate to repository base directory (cd dura)
4. Run cargo install --path . Note: If you receive a failure fetching the cargo dependencies try using the local git client for cargo fetches. CARGO_NET_GIT_FETCH_WITH_CLI=true cargo install --path .

Mac OS X

This installs dura and sets up a launchctl service to keep it running.

$ brew install dura

Windows

1. Download rustup-init
2. Clone this repository (e.g., git clone https://github.com/tkellogg/dura.git)
3. Navigate to repository base directory (cd dura)
4. Run cargo install --path . Note: If you receive a failure fetching the cargo dependencies try using the local git client for cargo fetches. CARGO_NET_GIT_FETCH_WITH_CLI=true cargo install --path .

Arch Linux

$ paru -S dura-git

Nix / Nixos

Nix is a tool that takes a unique approach to package management and system configuration. NixOS is a Linux distribution built on top of the Nix package manager.

To run dura locally using pre-compiled binaries:

nix shell nixpkgs#dura

If you're willing to contribute and develop, dura also provides its own ready-to-use Nix flake.

To build and run the latest development version of dura locally:

nix run github:tkellogg/dura

To run a development environment with the required tools to develop:

nix develop github:tkellogg/dura

FAQ

Is this stable?

Yes. Lots of people have been using it since 2022-01-01 without issue. It uses libgit2 to make the commits, so it's fairly battle hardened.

How often does this check for changes?

Every now and then, like 5 seconds or so. Internally there's a control loop that sleeps 5 seconds between iterations, so it runs less frequently than every 5 seconds (potentially a lot less frequently, if there's a lot of work to do).

Brought to you by Tim Kellogg.

dura's Issues

Option to ignore git hooks

Hey, great tool, thank you for making it. I do have one concern, though - some repositories I work on have extensive pre-commit scripts that do things like run the entire test suite and ensure that nothing fails. This would probably cause Dura's commits to fail as tests are more often than not broken while new code is being written.

I'm not familiar with Rust myself, but I'm not sure if git2's commit function supports the --no-verify flag, or if it skips git hooks by default.

How about a single branch mode?

I use git branch often, so I don't want to have hundreds of dura-HASH branches in the output, but I don't mind another static branch next to the master and staging. Is it possible to have just one dura branch, but keep snapshotting everything? I know that filtering out dura-HASH branches would be a solution to my problem, but still, I would like the single branch mode better.

P.S.: I'm very executed about this project for I've developed a habit of making a temporary commit every few minutes over the years, but your solution is better because it's automated ❤️

brew install dura

Hi, just wanted to share that Dura is now available on Homebrew, so Mac users can install it with:

brew install dura

Homebrew precompiles binaries for both x86-64 and arm64, so installation is pretty much instant 🎉

Ref: Homebrew/homebrew-core#106554

std::env::home_dir is deprecated

std::env::home_dir is deprecated as it tries to read the $HOME env variable on Windows. Should probably use home::home_dir from home instead (cargo and rustup use it).

Don’t create unnecessary branches

Right now, it creates a dura branch before a commit is created. This ends up leaving dura branches in the main Git log.

Dura could be less intrusive if it waited until it's certain a commit needs to be created to create the dura branch.

Tests broken

Hello,

This morning I upgraded rust to version 1.58 and I'm unable to run the tests. Did I do something wrong perhaps?

Here's the full log:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
$ git log -1
commit 1e1834dba821f2a8c87fca8aa6eaa00e24367512 (HEAD -> master, upstream/master, origin/master, origin/HEAD)
Author: dswij <[email protected]>
Date:   Fri Jan 14 14:18:03 2022 +0800

    chore: cleanup (#71)
$ cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.14s
$ cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.08s
     Running unittests (target/debug/deps/dura-19f8404b8c118cb7)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests (target/debug/deps/dura-73e01f6fdd7170ac)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/snapshots_test.rs (target/debug/deps/snapshots_test-e0f46cebc7bd3656)

running 6 tests
test test_commit_signature_exclude_git_config ... FAILED
test no_changes ... ok
test test_commit_signature_using_dura_config ... FAILED
test test_commit_signature_using_git_config ... FAILED
test change_single_file ... ok
test during_merge_conflicts ... ok

failures:

---- test_commit_signature_exclude_git_config stdout ----
$ git init
Initialized empty Git repository in /tmp/nix-shell.Ea9V9N/.tmpEIXWS4/.git/

$ git checkout -b master
Switched to a new branch 'master'

$ git config user.name git-author
$ git config user.email [email protected]
$ echo 'initial rev' > foo.txt
$ git add .
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   config.toml
        new file:   foo.txt


$ git commit -m test
$ echo 'change 1' > foo.txt
thread 'test_commit_signature_exclude_git_config' panicked at 'called `Result::unwrap()` on an `Err` value: Error { code: -9, klass: 4, message: "reference 'refs/heads/master' not found" }', tests/snapshots_test.rs:150:57
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- test_commit_signature_using_dura_config stdout ----
$ git init
Initialized empty Git repository in /tmp/nix-shell.Ea9V9N/.tmp4XRp2A/.git/

$ git checkout -b master
Switched to a new branch 'master'

$ git config user.name git-author
$ git config user.email [email protected]
$ echo 'initial rev' > foo.txt
$ git add .
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   config.toml
        new file:   foo.txt


$ git commit -m test
$ echo 'change 1' > foo.txt
thread 'test_commit_signature_using_dura_config' panicked at 'called `Result::unwrap()` on an `Err` value: Error { code: -9, klass: 4, message: "reference 'refs/heads/master' not found" }', tests/snapshots_test.rs:94:57

---- test_commit_signature_using_git_config stdout ----
$ git init
Initialized empty Git repository in /tmp/nix-shell.Ea9V9N/.tmpl3X4RV/.git/

$ git checkout -b master
Switched to a new branch 'master'

$ git config user.name git-author
$ git config user.email [email protected]
$ echo 'initial rev' > foo.txt
$ git add .
$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   config.toml
        new file:   foo.txt


$ git commit -m test
$ echo 'change 1' > foo.txt
thread 'test_commit_signature_using_git_config' panicked at 'called `Result::unwrap()` on an `Err` value: Error { code: -9, klass: 4, message: "reference 'refs/heads/master' not found" }', tests/snapshots_test.rs:120:57


failures:
    test_commit_signature_exclude_git_config
    test_commit_signature_using_dura_config
    test_commit_signature_using_git_config

test result: FAILED. 3 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.29s

error: test failed, to rerun pass '--test snapshots_test'
$

Disk usage concerns

A lobste.rs user is concerned about the disk usage. I've wondered the same thing myself.

Does anyone has ideas about how to get real data about how big of a problem this is?

I've wanted to build in some sort of GC, but it seems a little tough to get right. I could see doing it time-based or branch based (delete dura branches when their tracking branch is deleted). I'm in favor of branch-based, but there's still some corner cases (like, what if the dura branch is created against branch-1 but then you delete branch-1 and create branch-2 at the same commit?)

`dura capture` has no documentation

dura capture is a valid command in main. However, there is no documentation of the capture command (serve and watch are both documented in README.md).

The called fuction/file also contains no comment about the functionality.

How to ensure single daemon process?

Right now there are some safeguards to ensure that only a single daemon process is running.

Consequences of multiple daemons:

• Possible Git race condition on creating multiple commits
• Race conditions during logging
• Possible incomplete (corrupted) reads of the runtime database

Right now, we read the runtime database file at the beginning of each loop iteration. If the pid does not equal the current process' ID, then the process kills itself.

Please comment if you think this algorithm is inadequate.

More efficient update checking

Linux (and macOS) both support an event based API for file watching - perhaps this'd be more efficient than manually checking for updates?
https://crates.io/crates/inotify
https://crates.io/crates/kqueue
are existing bindings.

Dura fails to capture anything if a worktree is present as a subdir of the working directory

If you have an unignored worktree checked out in a subdirectory of the main working directory of a git repository, Dura will fail to capture any changes (whether by watch or capture).

Consider this example:

$ git init
$ echo 'beep' > boop
$ git add . && git commit -m 'initial commit'
$ dura capture # works correctly at this point
$ git worktree add -d wrktree HEAD
$ dura capture
Dura capture failed: invalid path: 'wrktree/'; class=Index (10)

If wrktree/ is added to .gitignore, Dura continues working fine.

This is admittedly a bit of an edge case, and perhaps an unconventional way to use worktrees, but Dura failing in this situation can also be a surprise to the user.

Feature Request: `dura status` command

I think it would be very useful to add a dura status command.

This should probably include whether or not the dura serve process is running, and it’s PID; a list of currently-watched git repos; and potentially the date/time (and tag?) of the most recent automatic commit done by dura serve, for each watched repository.

I'm not sure how that last part could be done without "knowing" the location of the log file (I run dura by using dura serve > $HOME/dura.log & so could extract it from ps, but presumably that won't always be the case).

Possible output assuming it's running, showing the time stamp but not the commit tag:

dura serve is running as PID 2756
Watching git repos:
“/home/user/repo1, last commit: 2022-02-15 14:20:35”
“/home/user/repo2, last commit: 2022-02-14 18:45:55”

If it's not running, then a line stating that, or just a non-zero status could be used.

--Paul.

Data Corruption: Don't allow dura to run as root

Runing dura serve as root will effectively corrupt repositories. Libgit2 will create things like lock files that can't be removed when not under sudo.

Repo

1. Run dura as root: sudo dura serve
2. Let it run for a while, the kill it
3. Run dura without root: dura serve
4. Tail the log and see Permission errors

Example log:

{"target":"dura::poller","file":"src/poller.rs","name":"event src/poller.rs:53","level":"Level(Info)","fields":{"message":"info_operation","operation":{"Snapshot":{"error":null,"latency":0.015587519,"op":{"base_hash":"8bafade2602688d23980b6c994418d656b7777d3","commit_hash":"d023fd3cb778ef99845657eaf102eb3cc2692c72","dura_branch":"dura/8bafade2602688d23980b6c994418d656b7777d3"},"repo":"/Users/timkellogg/code/oss/dura"}}},"time":"2022-11-29T18:32:46.552694+00:00"}

Desired state

Just fail if dura is started as root.

There's probably more sophisticated methods, like determining when a file is going to be written and handling it differently. But no, just keep it simple, don't let people root themselves. It's a data corruption risk.

stabilize config loading

related to #3

Currently, dura will read config from config file directly each time it needs to. Only loading config file when dura starts/reloaded is a nicer experience when a user is trying to change the config file (and suits well if dura planned to be a daemon)

Make dura branch names more informative

I'm brand new here, trying to find some easy way to make my first contribution to a Rust project, so I may be way off base as I am not a dura user. :)

Dura branches like dura/d4eaefdecb4ce75a2fd1666da5a8c15698eb8f86 could have more informative names to make recovery easier. Some options I've considered that could be mixed and matched:

• Mostly-sortable save time:
  • dura/2022-02-05_08-30AM (or a 24-hour format which is harder to read, but sortable)
• Some hint on the number of unstaged changes:
  • dura/2022-02-05_08-30AM_+127-12
• A snippet of the last changed code that maxes out the length of the branch name to 80 characters or something (this sounds hard, and questionably useful):
  • dura/2022-02-05_08:30AM_+127-12_model.py
  • dura/2022-02-05_08-30AM_+127-12_.about(Run-a-single-backup-of-an-entire-repository.-This-is-the-one-single-iteratio...

We could also be careful about the placement of slashes for git GUIs as mentioned in #47.

Would this be helpful? Do I have the UX flow totally off? If you like the idea, I'd like to take a whack at it. I imagine it will only be a few simple lines.

Edits:

• Maybe a helpful folder would be dura/<branch name that was copied>/<one of my suggestions>

Prevent pushin dura branches to remote

Some safeguards would be helpful to prevent accidentally poluting your remote with innumerable dura branches. Perhaps a git hook?

Add unwatch subcommand

There's no way to remove a directory from the watchlist.

Binaries built by Github are not working

Hi,

I'm trying to use a binary made by Github on my Linux laptop and I have this issue:

$ ./dura                                                                                                                                                                                                                         
Failed to execute process './dura'. Reason:
The file './dura' does not exist or could not be executed.
$ ldd dura                                                                                                                                                                                                                   
        linux-vdso.so.1 (0x00007ffd1d5bd000)
        libssl.so.1.1 => not found
        libcrypto.so.1.1 => not found
        libz.so.1 => not found
        libgcc_s.so.1 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libgcc_s.so.1 (0x00007f75be6f2000)
        libpthread.so.0 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libpthread.so.0 (0x00007f75be6d2000)
        libm.so.6 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libm.so.6 (0x00007f75be58f000)
        libdl.so.2 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libdl.so.2 (0x00007f75be58a000)
        libc.so.6 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib/libc.so.6 (0x00007f75be3c5000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/s9qbqh7gzacs7h68b2jfmn9l6q4jwfjz-glibc-2.33-59/lib64/ld-linux-x86-64.so.2 (0x00007f75bea64000)

I have the feeling that we should build it statically. I never did that yet in Rust, maybe you guys will know more about that.

Consider editing repository setings to remove "Packages" section

"Packages No packages published" is displayed right now, fortunately this pointless section can be removed.

Edit repo page config to remove it (cog next to the description).

I am not making a PR as it is defined in proprietary github settings, not in a git repository - and I have no rights to modify repo settings.

Maybe removing also releases section?

Homebrew cargo install instruction update suggestions

The current README.md install instructions state to perform the following to install dura.

Issue: Installation with homebrew needs updating

1. Install Rust (e.g., brew install rustup)
2. Clone this repository
3. Run cargo install --path .

The above did not provide the cargo executable so should be modified to the following

1. Install Rust (e.g., brew install rustup && brew install rust)

Issue: Cargo default configuration requires ssh-agent doesn't use ~/.ssh/config

Cargo default configuration will attempt to fetch using ssh-agent authentication. In many cases users may rely on settings in their ~/.ssh/config which are not referenced using cargo default git fetch.

To account for this the README.md could be updated to include an option for using the the local git client for fetching.

1. Install Rust (e.g., brew install rustup && brew install rust)
2. Clone this repository
3. Navigate to repository directory (cd dura)
4. Run cargo install --path . Note: If you receive a failure fetching the cargo dependencies try using the local git client for cargo fetches. CARGO_NET_GIT_FETCH_WITH_CLI=true cargo install --path .

Example output when default cargo settings fail to fetch git repo using ssh-agent

cargo install --path .
  Installing dura v0.1.0 (/Users/disaac/github/dura)
    Updating crates.io index
error: failed to compile `dura v0.1.0 (/Users/disaac/github/dura)`, intermediate artifacts can be found at `/Users/disaac/github/dura/target`

Caused by:
  failed to get `chrono` as a dependency of package `dura v0.1.0 (/Users/disaac/github/dura)`

Caused by:
  failed to load source for dependency `chrono`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to authenticate when downloading repository: [email protected]:rust-lang/crates.io-index

  * attempted ssh-agent authentication, but no usernames succeeded: `git`

  if the git CLI succeeds then `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  no authentication available

Update clap

Clap is currently out of date. There's a major version bump needed to v4.0 that causes a lot of build errors.

How to ensure the daemon starts, stays running, and watches the right Git repos

dura can't do anything for you if it's not running. How can we ensure that it's started & always running? I'd like dura to be nearly invisible after installation. It should "just work".

dura serve is setup so that the old process will finish it's loop iteration and then terminate. The new process overwrites ~/.config/dura/config.json with it's PID, and the old process terminates at the beginning of it's next iteration. (dura kill overwrites the pid with null, which causes the existing daemon to terminate itself).

Idea: start from ~/.bashrc or ~/.zshrc

When a new terminal session opens, it runs some file like ~/.bashrc. Here, we can run dura serve & to start & demonize it.

To make this work, add this to your ~/.bashrc or ~/.zshrc file:

dura serve &

Positives:

• It ensures that the demon starts
• Somewhat easy to setup

Negatives

• It only works if the user uses the terminal. Some people only use Git plugins via their editor.
• Doesn't restart failed daemons

Idea: bash/zsh prompt function

Set the user's prompt function to run dura serve &. This means it runs after every command

Positives

• Better assurance that the daemon keeps running at the right time
• We can also have the function do dura watch . on every directory we cd to, to ensure all Git repos are watched.

Negatives

• Harder to install (could be mitigated)
• Harder to support more shells
• Only works if the user uses the terminal. Some people only use Git plugins via their editor.

Idea: Git hook

Run dura serve & and dura watch . on a global Git hook (e.g. after pull & commit)

Positives

• You generally run git pull before doing any work, regardless if you use the Terminal or an IDE plugin
• Would target precisely the repos that you actually use.

Negatives

• Hook scripts are exclusive. If you wanted to run other hook scripts, you'd have to shut off the dura hooks.
• Doesn't include repos that you've already cloned & pulled. So there's a gap between when you install dura and when it actually does it's job correctly.

Improve "how to recover" experience

The readme outlines how to use a dura branch to recover, but it involves a lot of git-fu. It could be a lot easier

Idea: sub-commands

Add dura subcommands to do things like

• Get the branch corresponding to HEAD, e.g. dura head
• Get a commit by time frame, e.g. dura head 4h. I imagine this searching across dura branches, since we can indeed go prior to the HEAD commit.
• Recover to a specific commit hash (or a time frame).

Idea: Add help messages in relevant places

Documentation in the readme is great, but it could be better if we added help directly into messages that dura has to leave anyway. For example, why not set the commit message to something like:

dura auto-backup

To recover to this commit, run this:

<<git commands>>

Config file

I think a config file to change certain settings, like default branch name, check interval, and setting default username and email like #21 suggested, would be very helpful. Could be in your home directory called .dura in a format similar to a .gitignore.

`dura checkout` command

This isn't one that should be tackled until the branch changes (#9 & related) I reckon, but a command to instantly checkout a backup would be very powerful. This could potentially be coupled with a dura restore which merges/rebases/whatever a backup to the current branch.

Immediate thoughts are the command should take fixed and relative times, and round (up/down?) to the nearest backup. This would make it easy to find/recover a last known working version.

dura checkout 1h # check out backup from an hour ago
dura checkout 2022-01-10T17:00 # check out backup from timestamp

Ubuntu install instructions

I've been meaning to use Dura for a long time but always found the install to be rather unpleasant on Ubuntu.

I tried nix without success and then cargo- but it hits errors with both.

To get it to install on Ubuntu via cargo I needed to install two packages (as mentioned in this comment)

sudo apt install pkg-config libssl-dev

Perhaps the README could use those notes.

support install linux and macOS with brew

Can I make ppa repository with this source?
because, I want install and update this program with apt!

Dura doesn't create any branches on github codespaces

I'm new to using dura, so I might be doing something wrong. I've had dura running in the background for the last 30min or so (e.g. via dura serve &). See terminal output below;

@silvergasp ➜ /workspaces/embedded_controller (main ✗) $ ps
  PID TTY          TIME CMD
 3596 pts/0    00:00:00 bash
 5004 pts/0    00:00:00 dura
 7420 pts/0    00:00:00 ps
@silvergasp ➜ /workspaces/embedded_controller (main ✗) $ git branch
* main
@silvergasp ➜ /workspaces/embedded_controller (main ✗) $ 

Note that the only branch is the 'main' branch.

Note that this is running in Github codespaces on the latest version of ubuntu;

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.4 LTS
Release:        20.04
Codename:       focal

Update: Upgrade clap to V3.1.6 & replace deprecated code in main.rs

Hi,

while looking into adding the 'status' functionality, I received lots of warnings that clap 3.0.x functionality was now deprecated.

I have updated Cargo.toml & main.rs to use clap V3.1.6 and the new 'Command' functionality in my fork.

I can provide a PR with the changes if wanted.

-Paul (@PJC-64)

Set up releases and allow installation through package managers

Currently there's no easy way to download and install dura. Once the project comes into the later stages, someone should set up GitHub releases, as well as allowing dura to be installed with package managers like brew and apt-get.

Error: UnbornBranch

Repro

• Run dura serve
• Create a new repo, e.g. with cargo new, and make changes without committing
• Check the stdout log, there should be errors that look like:

{"target":"dura::poller","file":"src/poller.rs","name":"event src/poller.rs:41","level":"Level(Info)","fields":{"message":"info_operation","operation":{"Snapshot":{"error":"reference 'refs/heads/master' not found; class=Reference (4); code=UnbornBranch (-9)","latency":0.000267355,"op":null,"repo":"/Users/timkellogg/code/oss/syndr"}}},"time":"2022-11-28T14:27:18.611085+00:00"}

Expected behavior

This happens when there's no first commit. Normally the branch name is dura_{base_commit_hash}, in this case we could make it a constant dura_unborn or dura_init.

This also means that the first commit in sequence might not have a parent, which may cause other problems.

Shutting down because other poller took lock: None

I was running dura yesterday and it was working great. I think I accidentally closed the terminal it was running in and re-opened it, and now when I run dura serve I get this error:

$ dura serve
pid: 2285
Wrote /Users/dan/.config/dura/config.json
Shutting down because other poller took lock: None

My first thought was maybe I had another dura running but I don't think I do:

ps aux | grep dura
dan               2168   0.0  0.0 407963440    416 s001  R+   10:02AM   0:00.00 grep dura

Running dura kill didn't help either, I still get the same error when running dura serve.

Watch multiple directories at once

dura watch currently only processes the current directory. The readme could become a lot easier if we change main.rs to watch all directories passed. It should be a matter of calling snapshots::create in a loop.

After that, update the readme with the find ~ | xargs dura watch trick.

I personally like this approach because it's extremely flexible. While we'll probably implement more polished ways of discovering repos, someone will always need something like this.

Chronological git log

The Git log goes HEAD -> HEAD^ -> HEAD^^ -> .... This seems like chronological ordering, but it's not because it only follows the lineage of a single branch. I'd like to see a log that strictly orders by timestamp.

I imagine this as a dura log sub command that outputs plain text by default but also does JSON (for better tool integration).

Thoughts?

Better CLI implementation

The current CLI is fine, but the need to be in the current directory for some operations is a little annoying. The current implementation also makes it difficult to expand for more features (such as the WatchConfig fields added in #49 ).

I would suggest initially migrating the current code to use Clap or similar.

Commands could then be updated to the something like the below format:

dura serve # can be left as-is

# these default to cwd
dura watch [dir] [--include <includes>] [--exclude <excludes>] [--max-depth <depth>]
dura unwatch [dir]
dura capture [dir]

Panicked while starting the daemon server

• MacOS Monterey 12.1 (21C52) (Intel)
• rustc 1.57.0 (f1edd0429 2021-11-29)

On commit f4d552d.

Steps executed:

• brew install rustup
• rustup-init
• cargo install --path .
• RUST_BACKTRACE=1 dura serve

And got:

pid: 62355
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/config.rs:63:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
   2: core::result::unwrap_failed
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/result.rs:1616:5
   3: dura::config::Config::save
   4: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   5: tokio::park::thread::CachedParkThread::block_on
   6: tokio::runtime::thread_pool::ThreadPool::block_on
   7: tokio::runtime::Runtime::block_on
   8: dura::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Build Fail: Can't find GLIBC

@drupol This definitely seems like a NixOS environment issue. Can you take a look? On Ubuntu it's usually solved with installing some C/C++ tools, like gcc. Not really sure about NixOS.

https://github.com/tkellogg/dura/runs/4750159031?check_suite_focus=true

Log to stdout

Last night I made a change to log JSON to ~/.config/dura/logs/. However, writing to stdout has a lot of advantages when running with other tools, like systemd.

• Print to stdout by default
• Print to file if --log-file is specified

Get author and committer from a config variable or default out.

Neat idea. I think, for dura auto-commit vs. a human commit, it'd be nicer to distinguish the author and committer.

dura/src/snapshots.rs

Line 54 in c5c49d3

&head.author(),

feature request: remove old dura branches periodically

I think it's good to have a subcommand to remove old dura branches to clean up the clutter in git logs. Preferably, I can select the set of dura branches to be removed by time passed.

I'm not sure about removing it periodically, but at the minimum it's good to have a way to automatically remove dura branches.

Couldnt you just git commit more often?

It takes seconds to run the command. Not sure the necessity of this at all, and it may actually cause bad habits and behaviors that could lead to other sloppiness and waste in other areas of your life.

Errors when running the fish script

I was trying to run the fish script that @alin23 wrote. I ran into some issues with pgrep, command_exists, and and unmatched }. See below for terminal output.

sam@pop-os:~/Documents/repos/dura/scripts$ /usr/bin/env fish ./dura.fish
pgrep: invalid option -- 'q'

Usage:
 pgrep [options] <pattern>

Options:
 -d, --delimiter <string>  specify output delimiter
 -l, --list-name           list PID and process name
 -a, --list-full           list PID and full command line
 -v, --inverse             negates the matching
 -w, --lightweight         list all TID
 -c, --count               count of matching processes
 -f, --full                use full process name to match
 -g, --pgroup <PGID,...>   match listed process group IDs
 -G, --group <GID,...>     match real group IDs
 -i, --ignore-case         match case insensitively
 -n, --newest              select most recently started
 -o, --oldest              select least recently started
 -O, --older <seconds>     select where older than seconds
 -P, --parent <PPID,...>   match only child processes of the given parent
 -s, --session <SID,...>   match session IDs
 -t, --terminal <tty,...>  match by controlling terminal
 -u, --euid <ID,...>       match by effective IDs
 -U, --uid <ID,...>        match by real IDs
 -x, --exact               match exactly with the command name
 -F, --pidfile <file>      read PIDs from file
 -L, --logpidfile          fail if PID file is not locked
 -r, --runstates <state>   match runstates [D,S,Z,...]
 --ns <PID>                match the processes that belong to the same
                           namespace as <pid>
 --nslist <ns,...>         list which namespaces will be considered for
                           the --ns option.
                           Available namespaces: ipc, mnt, net, pid, user, uts

 -h, --help     display this help and exit
 -V, --version  output version information and exit

For more details see pgrep(1).
fish: Unknown command: command_exists
./dura.fish (line 7):
    if command_exists mktemp
       ^
in function 'tempfile'
    called on line 1 of file ./dura.fish
in command substitution
    called on line 14 of file ./dura.fish
WARNING: tempfile is deprecated; consider using mktemp instead.
fish: Unknown command: command_exists
./dura.fish (line 7):
    if command_exists mktemp
       ^
in function 'tempfile'
    called on line 1 of file ./dura.fish
in command substitution
    called on line 15 of file ./dura.fish
WARNING: tempfile is deprecated; consider using mktemp instead.
parse error: Unmatched '}' at line 1, column 24
Invalid number of arguments.
parse error: Unmatched '}' at line 1, column 24
parse error: Unmatched '}' at line 1, column 24

Working on pop-os (Ubuntu)

sam@pop-os:~/Documents/repos/dura/scripts$ fish --version
fish, version 3.1.2
sam@pop-os:~/Documents/repos/dura/scripts$ pgrep --version
pgrep from procps-ng 3.3.17

High CPU utilization while idle

Thank you for this amazing project!

I noticed high CPU usage while being idle. Is this a known issue?

`dura kill` has no documentation

dura kill is a valid command in main. However, there is no documentation of the kill command (serve and watch are both documented in README.md).

Use / in dura branch name to group dura branches together in git GUIs

The current implementation will clutter my branch list with dura- branches. If they were instead named dura/ or similar, then they would appear under a folder in most git GUIs, making them easier to hide until needed.

Address type-level crashes

This project is written in Rust so that the daemon can be very reliable. However, we have to actually take advantage of Rust's features to do that.

1. Remove all .unwrap() calls
2. Make cargo clippy pass