Better ergonomics for revision history

[rickycodes]

A bit of an assumption (on my part) was that changes wouldn't be shared/synced unless there were actual content changes made to the file(s)...

Consider the following workflow:

• DAT of post build website lives somewhere on disk
• website is built with x tool (make website, for example) somewhere else on disk
• new files are generated (as in new timestamp)
• copy said files over to aforementioned DAT location and share/sync
• discover that every file has been rewritten to DAT (revisions++)

ISTM that since there's such a heavy cost to the write (think images/video) dat cli shouldn't do anything unless there's a diff for that file in this case)? I had completely blown through my storage allotment on hashbase.io before I realized my folly

A prompt in the CLI before dat sync that indicates what the changes are with a [Y/n] prompt prior to sync would also make this clearer?

Related issues:

• https://github.com/datproject/dat/issues/941
• https://github.com/datproject/dat/issues/1036

[pfrazee]

(talked to him on IRC) Basically what @rickycodes is asking for is, can we get the Dat CLI to compare content with existing and not write a new revision to the dat if no change has occurred?