From my perspective, the main Dropbox feature that all the "thin layer on top of VCS" clones miss is the conflict-resolution behavior of Dropbox. If both you and someone else edit a file called "stuff.txt" at the same time, you'll end up with two files: "stuff.txt" and "stuff.txt (other guy's version)". Neither person's changes are blown away, there's never any merge conflicts, and the history remains linear.
I'll have to see if Gitdocs does anything like that.
It's not as simple as it sounds. What if there's already a file called "stuff.txt (other guy's version)"? There's lots and lots of edge cases. You basically need a function that can always return an appropriate but not-already-existing filename.
I think graceful file conflict resolution will be an essential part of gitdocs and we will work to handle these edge cases as best as we can. Thanks for bringing it up.
Although, if I'm reading this correctly, the logic isn't quite right. It uses the timestamp of the time when the conflict is detected, when it should really use the conflicted file's last-modified time, or maybe the timestamp of the conflicting commit.
I'll have to see if Gitdocs does anything like that.