Dura doesn't currently store any metadata about the branches it creates,so yeah currently users are stuck working with the generated hash-based branch names.

I think we're best avoiding the last two options as they'll generate extra complexity. Naming the branch after the datetime definitely makes sense though, and I do also like the idea of having changes shown. Being able to see immediately when a backup occurred and how much changed in that backup would be priceless when restoring.

These ideas might also feed nicely into my ideas in #70

The reason i went with hashes instead of dates is because the date is constantly changing, whereas the base hash is stable. What happens on snapshot? Does it

1. update the branch
2. delete old branch and create new one

(1) is more familiar to Git users, but it's not possible with date branches.

Some other ideas:

• Shorten the hash to make room for commit message
• Make better use of the first line of the commit message. Date, file changed (short version, like just base name), num lines changed, things like that.

I suggest this because the branch name sits behind 20 commits (at least for me), so making a useful branch name isn't that useful (imo) as it's buried in other commits. However, the first line of the commit message is featured prominently in most Git viewers. But space is at a premium, so think carefully on what you put there.

2022-02-18T14:59:07-0800:TagName 42 7 would be right out for a description of the 7th recent snapshot of uncommitted changes from a commit 42 commits after TagName in something like America/Phoenix time. Of course, instead of TagName it should be BranchName, but that's a more moveable feast. Had another thought or two they got away from me.