5 ms·

Even a force push doesn't destroy the reflog or runs the GC server-side. I wonder how you can accidentally loose data with Git. I've seen lot's of people not be

• cqqxo4zV46cp 3y ago
  Destroying it and nobody knowing how to recover, or that it can be recovered at all, it are identical.
• 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]
• billpg 3y ago
  I configured my github to only allow commits with an anonymised email address. Time passed and I used another machine on which I had already opened that repo before. I pulled my recent work successfully, wrote stuff and then committed and pushed. Github rejected my commit as I had the wrong email address. I then had to try and work out how I delete a commit but keep all my changes so I could commit it all again but with the correct email address. I'm not sure exactly what I did but in my ham-fisted experimentation I deleted the commit and restored my local copy back to the way it was before my commit, losing all my work that day.
  • BossingAround 3y ago
    If you had already committed, `git reflog` should have still found your changes (even after you deleted the commit and restored the local working tree) unless you deleted and re-cloned the repository.
  • fesc 3y ago
    Honestly I don’t understand why not more people use a GUI for git. What you describe would be 1 Minute of work and maybe 10 clicks with a very low probability of shooting yourself in the foot in Tower.
• noufalibrahim 3y ago
  I agree. It's quite hard to actually destroy data in git. Even with the so called "destructive" commands, walking through the reflogs can usually restore work that was accidentally deleted or whatever.
• grumbel 3y ago
  > doesn't destroy the reflog or runs the GC server-side. Git doesn't give you access to the server side reflog either. So it's of not much use if you don't control the server. As for losing data with Git, the easiest way to accomplish that is with data that hasn't been committed yet, a simple `git checkout` or `git reset --hard` can wipe out all your changes and even reflog won't keep record of that.
  • bvrmn 3y ago
    > As for losing data with Git, the easiest way to accomplish that is with data that hasn't been committed yet Also Git has pretty awful behavior losing changes when one doesn't press "Save" in their IDE. Bad, bad Git.
    • Spivak 3y ago
      Your applications also shouldn't lose work when you don't press save, this is the entire impetus for the "recover unsaved work" in most document editors. A version of Git that shunted uncommitted changes to a special named stash whenever you did anything destructive would be a positive thing. It's what I end up doing manually anyway but why make a system where the default behavior is destructive and I have to remember every.
      • xorcist 3y ago
        It may be prudent to note that git by default is rather kind in that way that it will not change your data unless you explicitly force it to with --force or --hard. I think git, as hard to learn as it can be, sometimes have a bit of an unfair reputation here. It's not all bad. Not only is it quite careful about not losing data, someone actually took the time to make it spit out messages that not only describes what just happened, but also gives suggestions of what to do next depending on how the user wants to proceed. That adds a level of discoverability that is usually associated with dialog based guis. The quality of these messages can sometimes be surprisingly good, far from the Clippy-level helpfulness you sometimes see. There are a few exceptions to the principle of not losing local changes, where you explicitly restore an old version of a file for example. But saying the default behaviour is destructive really gives a false impression. But yes, you are absolutely right that a system to recover unsaved work is a good thing, but I would argue that it belongs at the editor level, not in a version control system. A user could have a number of files open that have local changes. The editor has a much better idea in which order changes were made, and which changes hasn't even been committed to disk yet.