Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Repo: Consider adding a bot that asks not to force push when that happens #5170

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
JoshuaKGoldberg opened this issue Jun 11, 2022 · 9 comments
Labels
accepting prs Go ahead, send a pull request that resolves this issue repo maintenance things to do with maintenance of the repo, and not with code/docs

Comments

@JoshuaKGoldberg
Copy link
Member

Suggestion

The CONTRIBUTING.md asks not to force push. Yet a lot of PRs have force pushes. Clearly, not everyone is thoroughly reading+memorizing the contributing guides πŸ˜‰.

How about we add a bot that says a more professional version of: "hey don't sweat it that you already force pushed but please don't keep doing it; it makes it harder for us to review because XYZ and we squash merge anyway" ?

@JoshuaKGoldberg JoshuaKGoldberg added triage Waiting for team members to take a look repo maintenance things to do with maintenance of the repo, and not with code/docs labels Jun 11, 2022
@Josh-Cena
Copy link
Member

Can it actually be detected by a bot? I only know you can do it through a git pre-push hook, but not even a husky hook.

@JoshuaKGoldberg
Copy link
Member Author

JoshuaKGoldberg commented Jun 11, 2022

Heh good question. https://stackoverflow.com/questions/69882152/is-it-possible-to-check-a-git-push-force-in-a-github-action has a giant essay of info I'm tl;dr-ing, followed by maybe useful tips. Not super sold on that leading to a solution, but you never know.

https://stackoverflow.com/a/17503259/1830407 mentions there's a webhook capable event that includes a forced key. I found an example here: https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#webhook-payload-example-37

It would be nice for a clean+simple bot that we could open source for other repos to use ideally. But a webhook setup wouldn't be too much more work.

@Josh-Cena
Copy link
Member

Also, there's also a bit of a nuance here: for example, if a maintainer reviewed commit C1, and then I pushed C2 which I'm sure no-one has reviewed yet, I think it's fine for me to force-push the branch tip without re-writing C1. I do that quite often to correct silly typos in my last few commits.

@JoshuaKGoldberg
Copy link
Member Author

I'd still ask not to force push in that case though πŸ˜›. A couple reasons:

  • It will sometimes happen that a maintainer will check out C2 locally, such as a second review coming in after the first or when using the branch as a reference for some other work. And running gh pr checkout ... fails if history needs to be reset.
  • Other people will look at the PR and think it's ok to force push.

Let us see your typos!

@Josh-Cena
Copy link
Member

Eh, that's true. Hard to say which TZ the maintainer sits in these daysπŸ˜‰

Just that the typos make me seem like a bad programmer. Lol

@bradzacher
Copy link
Member

Me force pushing after I wrote the guide telling people not to force push

dd0.png

@bradzacher
Copy link
Member

Toooooo beeeeee fair.

When I wrote that GH sucked at handing force push. It meant you had no idea about what changes were made.

However now-a-days GH shows you a button that lets you compare before and after the force push.

Idk if we really need that stipulation any more

@Josh-Cena
Copy link
Member

I thought it's about incremental reviews? Does it un-collapse all viewed files when you force-push the entire branch?

@JoshuaKGoldberg
Copy link
Member Author

JoshuaKGoldberg commented Jun 11, 2022

There's that. I also find it annoying to review because it still messes with comments.

Edit: oh, and I think a lot of people are in the habit of doing it because other repos don't squash merges (another feature GH has put more love into the last couple of years). They assume they still need to do that extra effort in our repo. It's nice to let them know they don't.

@JoshuaKGoldberg JoshuaKGoldberg added accepting prs Go ahead, send a pull request that resolves this issue and removed triage Waiting for team members to take a look labels Jun 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepting prs Go ahead, send a pull request that resolves this issue repo maintenance things to do with maintenance of the repo, and not with code/docs
Projects
None yet
Development

No branches or pull requests

3 participants