5 ms·

He force pushed a diverged branch or something like that, and we only found out after a while. We were eventually able to recover because someone didn't pull. B

by sasham 3y ago

He force pushed a diverged branch or something like that, and we only found out after a while. We were eventually able to recover because someone didn't pull. But it was not a fun experience :D

School-Cotton 3y ago
So the work wasn’t actually destroyed, and you were able to recover it. So all the people pointing out how implausible that part of your pitch was were right, and you were in fact just lying.
- sasham 3y ago
  That's really not the main point of the post, but you're right I should have been more precise. Edit: updated in the top text now!
  - ysavir 3y ago
    I think the point being made is that you spent a lot of your opening post talking Git, and lead with that bit, rather than with Diversion. What makes Diversion different is added in the end, after you've spent time trying to convince Git fans that their current tooling isn't good. Worse, the examples you listed of why Git is bad is more reflective of configuration and processes than Git itself. This is ultimately a very weak pitching strategy. The first thing you convey to your potential users is insecurity--an insecurity that people won't choose your product over Git. And it's hard to want to buy something from someone that isn't secure enough about their product to pitch the product first, and answer questions/make comparisons after, as a form of clarification. Alternatively, instead of doing a comparison to Git, you could start with a list of "have you experienced these Git issues? <list of problems>. Here's how Diversion improves on Git in this regard." In this case you're actually solving people's problems, rather than looking like you're grasping at straws to complain about Git and justify an alternative. FWIW, I personally have 0 interest in a cloud-first version control. I like the cloud as a form of backup and syncing with team members, but I ultimately want a version control that works as well offline as it does online, and prioritizes the local experience.
  - School-Cotton 3y ago
    [flagged]
- IlliOnato 3y ago
  From my point of view, it's not that much about lying, for me the OP demonstrates a degree of incompetence of the post writers about Git. The fact that they don't seem to fully understand working of Git (not on the level of Git developers, just the level of Git administrators/users) does not inspire trust in their competence to create a Git alternative.
bauruine 3y ago
So multiple people did a git reset --hard origin/master and nobody complained or checked what and why this was done? That's not "one data scientist with the wrong command" but the whole team that fucked up hard IMHO.
- lonelyasacloud 3y ago
  > but the whole team that fucked up hard IMHO. Multiple individuals with similar problems would tend to imply systematic inadequate training. Or the enterprise concerned adopting an inappropriately complex system for its intended userbase.
  - willy_k 3y ago
    Or, git is both very complex and very useful, and a large portion of its users have a poor understanding of git but enough for it to be a useful tool. If you want to do source control (which you do), then you’re investing time into learning git and/or fixing git, or maybe using a project like this.
    - keerthiko 3y ago
      You literally just said what GP said in different words, but prefaced it with "Or" as if it's a disagreement. What you said boils down to "inadequate training".
      - willy_k 3y ago
        We both agree that they didn’t know the tool, but GP seems to blame them for deciding to use the tool without training. I was more or less defending their choice to use git, while also acknowledging the potential of a tool like Diversion. My interpretation of GP was that it doubled down on git, while claiming that anyone using git without understanding it is “doing it wrong”, which I agree with in principle but not in practice, as I argued in my initial comment.
- NateEag 3y ago
lawgimenez 3y ago
So you were able to recover and did not lost a months work of data? Your story just doesn’t make sense. Come on.
- egaldv 3y ago
  Indeed you're right the work that was erased from BitBucket was restored from one of the employees that didn't yet pull, the post was edited accordingly.
  - School-Cotton 3y ago
    Wouldn’t you still have been able to recover it even if everyone did pull, assuming GC had not run on everyone’s machine?
  - sampo 3y ago
    > the work that was erased from BitBucket was restored from one of the employees that didn't yet pull Actually those commits that you considered lost, were still stored on everyone's personal computer in your team. You just didn't know how to use `git reflog` to find them.
sbergot 3y ago
For your information you can use the reflog command to find the previous head commit and restore your branch. It takes 10 minutes and then you learn to disable force pushing on the main branch.
- swells34 3y ago
  I find it funny how many comments in this angry rebuttal section actually endorse a Git replacement.
  - plagiarist 3y ago
    It's an interesting new application of that joke, "when I have a question on Linux I use a sock puppet account to leave an obviously wrong answer which prompts dozens of corrections." I'm trying to imagine how to generalize this to other products. I think if I state the competing product has negative feature X, but also intentionally get some details confidently incorrect or deliberately feign incompetence, you get a group of people confirming X.
  - spiderice 3y ago
    I find it funny how many comments you've made in this thread missing the point. People are reacting against the dishonest pitch, not the product.
renewiltord 3y ago
Just somewhat surprised because if anyone did a `git pull` they'd get divergent history and therefore a merge on default configuration. It would take a lot of manual work to ruin more than one copy of the repo.
wakawaka28 3y ago
[dead]

by sasham 3y ago

He force pushed a diverged branch or something like that, and we only found out after a while. We were eventually able to recover because someone didn't pull. But it was not a fun experience :D

School-Cotton 3y ago

So the work wasn’t actually destroyed, and you were able to recover it. So all the people pointing out how implausible that part of your pitch was were right, and you were in fact just lying.

sasham 3y ago
That's really not the main point of the post, but you're right I should have been more precise. Edit: updated in the top text now!
- ysavir 3y ago
  I think the point being made is that you spent a lot of your opening post talking Git, and lead with that bit, rather than with Diversion. What makes Diversion different is added in the end, after you've spent time trying to convince Git fans that their current tooling isn't good. Worse, the examples you listed of why Git is bad is more reflective of configuration and processes than Git itself. This is ultimately a very weak pitching strategy. The first thing you convey to your potential users is insecurity--an insecurity that people won't choose your product over Git. And it's hard to want to buy something from someone that isn't secure enough about their product to pitch the product first, and answer questions/make comparisons after, as a form of clarification. Alternatively, instead of doing a comparison to Git, you could start with a list of "have you experienced these Git issues? <list of problems>. Here's how Diversion improves on Git in this regard." In this case you're actually solving people's problems, rather than looking like you're grasping at straws to complain about Git and justify an alternative. FWIW, I personally have 0 interest in a cloud-first version control. I like the cloud as a form of backup and syncing with team members, but I ultimately want a version control that works as well offline as it does online, and prioritizes the local experience.
- School-Cotton 3y ago
  [flagged]
IlliOnato 3y ago
From my point of view, it's not that much about lying, for me the OP demonstrates a degree of incompetence of the post writers about Git. The fact that they don't seem to fully understand working of Git (not on the level of Git developers, just the level of Git administrators/users) does not inspire trust in their competence to create a Git alternative.

bauruine 3y ago

So multiple people did a git reset --hard origin/master and nobody complained or checked what and why this was done? That's not "one data scientist with the wrong command" but the whole team that fucked up hard IMHO.

lonelyasacloud 3y ago
> but the whole team that fucked up hard IMHO. Multiple individuals with similar problems would tend to imply systematic inadequate training. Or the enterprise concerned adopting an inappropriately complex system for its intended userbase.
- willy_k 3y ago
  Or, git is both very complex and very useful, and a large portion of its users have a poor understanding of git but enough for it to be a useful tool. If you want to do source control (which you do), then you’re investing time into learning git and/or fixing git, or maybe using a project like this.
  - keerthiko 3y ago
    You literally just said what GP said in different words, but prefaced it with "Or" as if it's a disagreement. What you said boils down to "inadequate training".
    - willy_k 3y ago
      We both agree that they didn’t know the tool, but GP seems to blame them for deciding to use the tool without training. I was more or less defending their choice to use git, while also acknowledging the potential of a tool like Diversion. My interpretation of GP was that it doubled down on git, while claiming that anyone using git without understanding it is “doing it wrong”, which I agree with in principle but not in practice, as I argued in my initial comment.
NateEag 3y ago

lawgimenez 3y ago

So you were able to recover and did not lost a months work of data? Your story just doesn’t make sense. Come on.

egaldv 3y ago
Indeed you're right the work that was erased from BitBucket was restored from one of the employees that didn't yet pull, the post was edited accordingly.
- School-Cotton 3y ago
  Wouldn’t you still have been able to recover it even if everyone did pull, assuming GC had not run on everyone’s machine?
- sampo 3y ago
  > the work that was erased from BitBucket was restored from one of the employees that didn't yet pull Actually those commits that you considered lost, were still stored on everyone's personal computer in your team. You just didn't know how to use `git reflog` to find them.

sbergot 3y ago

For your information you can use the reflog command to find the previous head commit and restore your branch. It takes 10 minutes and then you learn to disable force pushing on the main branch.

swells34 3y ago
I find it funny how many comments in this angry rebuttal section actually endorse a Git replacement.
- plagiarist 3y ago
  It's an interesting new application of that joke, "when I have a question on Linux I use a sock puppet account to leave an obviously wrong answer which prompts dozens of corrections." I'm trying to imagine how to generalize this to other products. I think if I state the competing product has negative feature X, but also intentionally get some details confidently incorrect or deliberately feign incompetence, you get a group of people confirming X.
- spiderice 3y ago
  I find it funny how many comments you've made in this thread missing the point. People are reacting against the dishonest pitch, not the product.

renewiltord 3y ago

Just somewhat surprised because if anyone did a `git pull` they'd get divergent history and therefore a merge on default configuration. It would take a lot of manual work to ruin more than one copy of the repo.

wakawaka28 3y ago

[dead]