5 ms·

> Isn't that exactly what a revision control system is for? Unfortunately, some allow you to re-write all history.

Silhouette 13y ago
Right. So if your revision control system -- your failsafe in the event of unpredicted mistakes -- is configured such that you can lose data permanently, I think it is fair to ask whether anything can be changed to improve how that tool operates. This doesn't mean you can't also ask what else might be done to avoid any unfortunate repetition of the same problem situation, of course.
- jrochkind1 13y ago
  Nothing was or could have been lost permanently. The commits were all still there, it's just that none of them were in the commit history for any branches anymore. And the entire history including sufficient info to restore the state prior to the `push -f` is all there in the reflog. It's just a pain in the butt to restore it all, especially if in the meantime people started making new commits on top. But if someone has commit privileges to a repo, they have the ability to mess it up, I don't see any real way around that. The UI of the client side tool(s) that made it so easy to make this mistake can perhaps be blamed.
  - eru 13y ago
    > But if someone has commit privileges to a repo, they have the ability to mess it up, I don't see any real way around that. Force push capabilities make it even easier to mess up than just plain commit priviliges.
deleted 13y ago
[deleted]
jarrett 13y ago
But even this is necessary sometimes. Yes, it seems counterintuitive that a version control system should ever let you lose previously committed data. "What's the point of version control, if there's a chance you won't be able to revert?" you might ask. So at first it seems like we should establish the principle that you can't permanently delete committed data. (Unless you step outside the tools provided by the VCS and do something like hacking the contents of the .git directory.) But sadly, real-world constraints get in the way of this principle. Disk space is one such constraint. Sometimes, we need to bring a repo's disk footprint down to a reasonable size. This could happen if we committed a bunch of huge files that we no longer want, or if the repo is simply very old. Another constraint is intellectual property, secrets, passwords, and such things. Sometimes you check in something that other people shouldn't see. Maybe it's an accident, or maybe you just don't realize the data is sensitive. You need a way to redact the contents of the repo, and that means deleting historical data.
- aragot 13y ago
  All the examples you provide are right, because they happen seldomly. Unfortunately, in git, --force is part on the everyday workflow.
  - sitharus 13y ago
    What sort of workflow are you using when you need to use --force every day? The company I work for has at least 50 projects all using Git and the only time we use --force is when we have to clean up a major mistake (eg a premature merge to release). I can count the number of times this has happened in the past 3 years on my hands.
    - deleted 13y ago
      [deleted]
  - jarrett 13y ago
    I had no idea people were using --force daily. I've been using Git for all my version control since 2008, and I don't think I've ever used --force. Now I'm curious: How does it fit into people's everyday workflow?
    - nickstinemates 13y ago
      I use it when cleaning up pull requests. Rebase and squash. Fix commit messages. Force push to PR-branch tidy.
      - phaemon 13y ago
        Why would you do this, rather than pull into a different branch name, fix it there, and then merge it in? Is there an advantage to doing it by altering your own repo?
        nickstinemates 13y ago
        I am talking about editing history and squashing commits. For cleaner merges.
deleted 13y ago
[deleted]
cjh_ 13y ago
In the case of git 'rewriting history' is not really the problem, and it leaves the old history intact (you cannot change git history, but you can create an alternative history). The old history will possibly be garbage collected eventually, but for quite a while that history is still accessible. I think the only missing piece is a simple (and obvious) client side 'undo/rollback that force push'. The issue is that the git client may not have the history pre-force, so it may have insufficient information to do the rollback (at least in the current model), however the server still has all the refs (and they are listed in the reflog).
- bereft_orange 13y ago
  Yes, the ability to rollback history more easily than paging through `git reflog` would be great. (in particular, if you rebase often you end up with a lot of cruft).
  - cjh_ 13y ago
    Locally in git you have the HEAD@{n} notation to step back n steps through the reflog, so after a bad rebase a `git reset --hard HEAD@{1}` should be all you need.

Right. So if your revision control system -- your failsafe in the event of unpredicted mistakes -- is configured such that you can lose data permanently, I think it is fair to ask whether anything can be changed to improve how that tool operates. This doesn't mean you can't also ask what else might be done to avoid any unfortunate repetition of the same problem situation, of course.

jrochkind1 13y ago
Nothing was or could have been lost permanently. The commits were all still there, it's just that none of them were in the commit history for any branches anymore. And the entire history including sufficient info to restore the state prior to the `push -f` is all there in the reflog. It's just a pain in the butt to restore it all, especially if in the meantime people started making new commits on top. But if someone has commit privileges to a repo, they have the ability to mess it up, I don't see any real way around that. The UI of the client side tool(s) that made it so easy to make this mistake can perhaps be blamed.
- eru 13y ago
  > But if someone has commit privileges to a repo, they have the ability to mess it up, I don't see any real way around that. Force push capabilities make it even easier to mess up than just plain commit priviliges.

deleted 13y ago

[deleted]

jarrett 13y ago

But even this is necessary sometimes. Yes, it seems counterintuitive that a version control system should ever let you lose previously committed data. "What's the point of version control, if there's a chance you won't be able to revert?" you might ask. So at first it seems like we should establish the principle that you can't permanently delete committed data. (Unless you step outside the tools provided by the VCS and do something like hacking the contents of the .git directory.) But sadly, real-world constraints get in the way of this principle. Disk space is one such constraint. Sometimes, we need to bring a repo's disk footprint down to a reasonable size. This could happen if we committed a bunch of huge files that we no longer want, or if the repo is simply very old. Another constraint is intellectual property, secrets, passwords, and such things. Sometimes you check in something that other people shouldn't see. Maybe it's an accident, or maybe you just don't realize the data is sensitive. You need a way to redact the contents of the repo, and that means deleting historical data.

aragot 13y ago
All the examples you provide are right, because they happen seldomly. Unfortunately, in git, --force is part on the everyday workflow.
- sitharus 13y ago
  What sort of workflow are you using when you need to use --force every day? The company I work for has at least 50 projects all using Git and the only time we use --force is when we have to clean up a major mistake (eg a premature merge to release). I can count the number of times this has happened in the past 3 years on my hands.
  - deleted 13y ago
    [deleted]
- jarrett 13y ago
  I had no idea people were using --force daily. I've been using Git for all my version control since 2008, and I don't think I've ever used --force. Now I'm curious: How does it fit into people's everyday workflow?
  - nickstinemates 13y ago
    I use it when cleaning up pull requests. Rebase and squash. Fix commit messages. Force push to PR-branch tidy.
    - phaemon 13y ago
      Why would you do this, rather than pull into a different branch name, fix it there, and then merge it in? Is there an advantage to doing it by altering your own repo?
      - nickstinemates 13y ago
        I am talking about editing history and squashing commits. For cleaner merges.

deleted 13y ago

[deleted]

cjh_ 13y ago

In the case of git 'rewriting history' is not really the problem, and it leaves the old history intact (you cannot change git history, but you can create an alternative history). The old history will possibly be garbage collected eventually, but for quite a while that history is still accessible. I think the only missing piece is a simple (and obvious) client side 'undo/rollback that force push'. The issue is that the git client may not have the history pre-force, so it may have insufficient information to do the rollback (at least in the current model), however the server still has all the refs (and they are listed in the reflog).

bereft_orange 13y ago
Yes, the ability to rollback history more easily than paging through `git reflog` would be great. (in particular, if you rebase often you end up with a lot of cruft).
- cjh_ 13y ago
  Locally in git you have the HEAD@{n} notation to step back n steps through the reflog, so after a bad rebase a `git reset --hard HEAD@{1}` should be all you need.