Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing the Revert Button

github.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Introducing the Revert Button

#11

Post by mvermaat »

benatkin wrote: post #10
mvermaat wrote: post #8

Earlier quoted context omitted.

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.

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

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.

Re: Introducing the Revert Button

#12

Post by 4mnt »

benatkin wrote: post #10
mvermaat wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: Introducing the Revert Button

#14

Post by cpeterso »

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.

Re: Introducing the Revert Button

#15

Post by Chris911 »

cpeterso wrote: post #14

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.

Re: Introducing the Revert Button

#17

Post by derefr »

jonny_eh wrote: post #13

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.

Re: Introducing the Revert Button

#18

Post by smsm42 »

cpeterso wrote: post #14

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.

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.

Re: Introducing the Revert Button

#19

Post by js2 »

mvermaat wrote: post #8
benatkin wrote: post #5

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 e…

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.
Post reply on HN