3 ms·
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 nee
by rcthompson 15y ago
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.
- nesquena 15y agoI 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.
- hbons 15y agoYou might want to look at this bit: https://github.com/hbons/SparkleShare/blob/master/SparkleLib/Git/SparkleRepoGit.cs#L293 https://github.com/hbons/SparkleShare/blob/master/SparkleLib... It tries to copy the Dropbox conflict behaviour.
- rcthompson 15y agoInteresting. I'll have to try it out again. 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.
- lloeki 15y ago"stuff.txt (sha1)" works. User-friendliness of it depends of user base (and might actually be a feature as it traces back to the exact history point)