5 ms·
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
by 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 agoAll the examples you provide are right, because they happen seldomly. Unfortunately, in git, --force is part on the everyday workflow.
- sitharus 13y agoWhat 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 agoI 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 agoI use it when cleaning up pull requests. Rebase and squash. Fix commit messages. Force push to PR-branch tidy.
- phaemon 13y agoWhy 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 agoI am talking about editing history and squashing commits. For cleaner merges.
- gcb1 13y agoBut you should do that locally and then push without force.
- swift 13y agoIf you're working in an organization that employs pre-merge code review, you may have to modify your topic branch several times before it's ready to be merged into the main development branch. Creating a new branch every time so that you can push without force seems pointless in this case and increases confusion for everyone involved in the process.
- lmm 13y agoYes, but you can pull into a new local branch, do the history edit there, and then push that new branch, can't you? Not that I'm sure it would be worth it.
- encoderer 13y agoIt's used often in a team where you each have your own forks. It's much less risky in such a case, of course. Basically, I push to my fork, then later I pull-with-rebase from the mainline, then I push again to my fork. Oops, commit hashes have changed because of my pull-with-rebase. So I need to either push to a different branch or force push.