Hacker News Reader

Comment by darkarmani | Hacker News Reader

> Isn't that exactly what a revision control system is for?

Unfortunately, some allow you to re-write all history.

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).

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).

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.

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.

> 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.

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.

All the examples you provide are right, because they happen seldomly. Unfortunately, in git, --force is part on the everyday workflow.

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.

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?

It'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.

Your problem is that you shouldn't be doing pull with rebase so often. A clean merge doesn't have to rewrite anything.

I'm not sure a "problem" exists here. Keeping your personal topic branch rebased on top of the main development branch is a perfectly reasonable workflow, and quite comparable to what you'd do with Mercurial patch queues.

And in a team where everybody's used to that, and force is only ever used on topic branches where that's the expected 'done thing', it really doesn't cause a problem.

(on teams that like rebase I tend to do this a lot)

Exactly. Though it is a bit of a moral hazard... or maybe that's not the right term... point is, users get used to "-f" ing pushes.

Agree with Swift. Having a rebase strategy keeps history linear and MUCH easier to read.

I use it when cleaning up pull requests.

Rebase and squash. Fix commit messages. Force push to PR-branch tidy.

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?

I am talking about editing history and squashing commits. For cleaner merges.

Yes, 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.

But you should do that locally and then push without force.

If 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.

Reply on news.ycombinator.com