7 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

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 being able to find it, but really destroying it is hard.

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!
    - School-Cotton 3y ago
      [flagged]
    - 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.
  - 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.
  - NateEag 3y ago
    And the tool made a screwup that hard not only possible, but very difficult for the victims to recover from. Doesn't say a lot for git's usability.
    - funcDropShadow 3y ago
      They used --force which is usually the flag to say: Here there be dragon. Be careful.
      - mbreese 3y ago
        Yeah, I can’t see how use of a —-force flag by people who didn’t know what they were doing is enough of a reason to switch to a different VCS (let alone write one). The issue was people using a tool in a way that they shouldn’t have. Which isn’t a technical problem, but a training problem. You can’t fix people problems with technology, so I’m sure there will be other footguns in this new system that someone else will figure out how to almost lose data. Git is great in that it is flexible and powerful. But that power leaves some tools open to people who don’t know what they are doing… that’s the trade off. (Now something that better handles non-code assets and large data files, I’d be much more willing to listen to that pitch.)
    - JeremyNT 3y ago
      A couple of thoughts about this: One is that the possibility of overwriting history / etc is a really powerful and useful feature, but one that should only be used with some consideration, hence being gated behind the scary '--force'. The fact that git provides one the ability to discard and overwrite commits for a ref shouldn't be an endorsement of doing so freely. I'm glad git has this capability though and any "git alternative" would be all the worse if it didn't provide it, IMO. Two is that if the concern is git's usability - i.e. the "problem" here is that it's too "easy" for users to do destructive actions accidentally - well, there are ways to solve that other than to reinvent all of git. There are plenty of alternative git UIs already, and an alternative UI is a great way to be "wire compatible" for existing users but still help protect those novice users from footguns.
- 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.

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!
  - School-Cotton 3y ago
    [flagged]
  - 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.
- 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.
- NateEag 3y ago
  And the tool made a screwup that hard not only possible, but very difficult for the victims to recover from. Doesn't say a lot for git's usability.
  - funcDropShadow 3y ago
    They used --force which is usually the flag to say: Here there be dragon. Be careful.
    - mbreese 3y ago
      Yeah, I can’t see how use of a —-force flag by people who didn’t know what they were doing is enough of a reason to switch to a different VCS (let alone write one). The issue was people using a tool in a way that they shouldn’t have. Which isn’t a technical problem, but a training problem. You can’t fix people problems with technology, so I’m sure there will be other footguns in this new system that someone else will figure out how to almost lose data. Git is great in that it is flexible and powerful. But that power leaves some tools open to people who don’t know what they are doing… that’s the trade off. (Now something that better handles non-code assets and large data files, I’d be much more willing to listen to that pitch.)
  - JeremyNT 3y ago
    A couple of thoughts about this: One is that the possibility of overwriting history / etc is a really powerful and useful feature, but one that should only be used with some consideration, hence being gated behind the scary '--force'. The fact that git provides one the ability to discard and overwrite commits for a ref shouldn't be an endorsement of doing so freely. I'm glad git has this capability though and any "git alternative" would be all the worse if it didn't provide it, IMO. Two is that if the concern is git's usability - i.e. the "problem" here is that it's too "easy" for users to do destructive actions accidentally - well, there are ways to solve that other than to reinvent all of git. There are plenty of alternative git UIs already, and an alternative UI is a great way to be "wire compatible" for existing users but still help protect those novice users from footguns.
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.