3 ms·

> In our previous startup, a data scientist accidentally destroyed a month’s work of his team by using the wrong Git command. While git is indeed a usability

> In our previous startup, a data scientist accidentally destroyed a month’s work of his team by using the wrong Git command. While git is indeed a usability clusterbomb and there is massive space to improve, the problem above sounds like a devops failure. Git gives you all the tools to prevent such a disaster, all you have to do not give the root password of your CI server to any data scientist. On the topic of your startup, I would very much like a lighter learning slope, where I can introduce regular non-coders to the benefits of source control, and still have the advanced brancing/merging/rebasing etc. for the wizards.

sasham 3y ago
True! They didn't actually have a root pwd to anything, the repo was hosted on BitBucket which didn't have a branch protection feature back then. Non-coder users are actually an important use case for Diversion (like in game development where many/most users are artists).
- jsnell 3y ago
  And nobody on the team had a reasonably fresh checkout of the repo on their local machine? To put it bluntly, this story does not sound credible. It's also one of the first things you say in the pitch, which taints everything you write later. I would suggest focusing on what you do well, not in making up stories about data loss with what you perceive as the competition. (It's especially odd when Git isn't the obvious competition; Perforce is.)
  - sasham 3y ago
    Swear to god, the story is true! We were able to restore most of the work because someone didn't pull the updates. (I should have added it in the story, didn't think it was important) But it was nerve wracking :')
    - dmazzoni 3y ago
      But if someone DID pull the update, the old commits would have still been in their local repo and they could have run "git reflog" to retrieve them.
      - xorcist 3y ago
        The person, who apparently googled some command sequence and happily entered them only to find out it overwrote the team's data, could just as easily have used those google skills to search for how to undo last git operation. Obviously this person had all the privileges required to force push the previous commit in order to save the day. The old adage of never fact-checking a good story holds true however. Not sure it's a good selling point though, by nerd sniping everyone to explain in detail what the actual problem was no one will read to the end.
sgarland 3y ago
I also always wonder in cases like this if the person just didn’t know about reflog. You _really_ have to try to fuck up hard enough that everything is gone, it just might require even more arcane commands than what got you into a mess.
- faitswulff 3y ago
  I've used reflog many times, but I'm not sure if this: > You _really_ have to try to fuck up hard enough that everything is gone ...is still true when using git-lfs, which seems common when using large data sets.
  - sbergot 3y ago
    I believe it works the same. The large files are not immediately pruned.

sasham 3y ago

True! They didn't actually have a root pwd to anything, the repo was hosted on BitBucket which didn't have a branch protection feature back then. Non-coder users are actually an important use case for Diversion (like in game development where many/most users are artists).

jsnell 3y ago
And nobody on the team had a reasonably fresh checkout of the repo on their local machine? To put it bluntly, this story does not sound credible. It's also one of the first things you say in the pitch, which taints everything you write later. I would suggest focusing on what you do well, not in making up stories about data loss with what you perceive as the competition. (It's especially odd when Git isn't the obvious competition; Perforce is.)
- sasham 3y ago
  Swear to god, the story is true! We were able to restore most of the work because someone didn't pull the updates. (I should have added it in the story, didn't think it was important) But it was nerve wracking :')
  - dmazzoni 3y ago
    But if someone DID pull the update, the old commits would have still been in their local repo and they could have run "git reflog" to retrieve them.
    - xorcist 3y ago
      The person, who apparently googled some command sequence and happily entered them only to find out it overwrote the team's data, could just as easily have used those google skills to search for how to undo last git operation. Obviously this person had all the privileges required to force push the previous commit in order to save the day. The old adage of never fact-checking a good story holds true however. Not sure it's a good selling point though, by nerd sniping everyone to explain in detail what the actual problem was no one will read to the end.

sgarland 3y ago

I also always wonder in cases like this if the person just didn’t know about reflog. You _really_ have to try to fuck up hard enough that everything is gone, it just might require even more arcane commands than what got you into a mess.

faitswulff 3y ago
I've used reflog many times, but I'm not sure if this: > You _really_ have to try to fuck up hard enough that everything is gone ...is still true when using git-lfs, which seems common when using large data sets.
- sbergot 3y ago
  I believe it works the same. The large files are not immediately pruned.