Make dura branch names more informative

[chrisranderson]

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>

[JakeStanger]

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

[tkellogg]

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.

[JamesB192]

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.