Introducing the Revert Button | Hacker News Reader

Introducing the Revert Button

github.com

117 points_pius18 comments

I think it would be neat if GitHub detected and archived branches that are deleted or overwritten with force --push. I don't know how feasible this is but it would make it more true that when code is pushed to GitHub, it's safe.

Edit: what I have in mind is something like a Recycle Bin or Trash for deleted branches where you can restore a branch (with a different name, if needed) or delete it permanently. Not some esoteric git feature. I'd like if it were added to git (as an optional feature enabled in .git/config), but I'd want it to work more like stash than a feature for searching for things that were left behind.

I think that (and correct me if I'm wrong) what you're really asking for is for the reflog to be exposed in some way.

Certainly I've force pushed before when I didn't mean to. When I went asking where the reflog was they (politely) offered to dig into my repo and give me a copy of my reflog. But I would have preferred if this was something that I could see easily myself.

In a way that's already true, since the commits are still there (and included when you clone). They're just not discoverable.

It would be neat though if GitHub added some UI magic to recover dangling commits, possibly using the knowledge of which branches previously pointed to them and/or push -f operations.

You only get the commits reachable from the refs you clone. i.e. anything under refs/heads/* by default. Unless a commit is reachable from a ref you can fetch, it is not retrievable to you and won't be in your clone. So unless GitHub can locate it via reflog and create a ref, you won't be able to access it.

Aren't these part of what gets cleaned up by git gc?

Yes they are. But only after they get dropped from the reflog, after 30 days by default.

That is true, but only when they're older than 2 weeks (or whatever you define with --prune). I don't know what GitHub's configuration is here.

I'd like to see a "Squash pull request" button to avoid merge commits, clean up messy pull requests with WIP commits and changes to address review feedback, and keep master bisectable at every commit.

That would be awesome. The interface should be just like when you rebase and you get to select which commit you want to squash or keep.

Yes, squash would be awesome. I've had a number of cases where I had to d/l the pull request only to squash a long-running feature branch that is now ready for merge but has a lot of junk "work in progress" commits. It's be nice to be able to clean it up right in github.

This will be a huge help for teams of larger developers who use Github.

It's really easy for a branch to "look okay" at the unit level (generally covered by the commit status API) and then completely fail at the integration level.

Enabling quick reverts of bad code encourages people to make the "right fix" rather than trying to hotfix issues in an integration environment (which blocks the rest of the team and prevents other features from going out).

Kind of ironic how Github continues to make it less necessary for developers to actually learn git.

Why would it not be their goal to abstract away the pain? Sure, you still have the power of git available to you, but not everyone who uses Github may want to learn git. They may simply be looking for versioning of their assets (images, geojson, etc).

And I personally couldn't be happier; most of the projects I'm involved with use Mercurial. So to me, git's interface is difficult to understand and foreign despite my own efforts to try to lean it.

GitHub and SourceTree combined have taken all the pain way from me using git.

Why is that ironic at all?

This is an awesome feature - not one you'll use every day, but one that's very convenient when you've made an oops.

This is great! But why is it only for PRs? Why not any arbitrary commit?

A developer can revert their own commits on their own branches well-enough by using `git revert`.

This is more for Github's "Enterprise-y" (or "distributed FOSS project-y") workflow, where you have

• a project maintainer, who never touches git, and works entirely through Github, interacting mostly with the issue tracker and only modifying the codebase by accepting/rejecting pull-requests; and

• a set of developers, who actually use git, and generate pull-requests to submit to the maintainer.

Until now, if the non-git-using maintainer accepted a pull-request they shouldn't have, they would have to get one of the developers to create a reverting commit, create a PR for that commit, and then accept the PR. Now they can just revert the PR itself.

Reply on news.ycombinator.com