Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah, I always force push. I always treat PRs as one atomic unit ("squash and merge") and the history that goes into the PR isn't relevant to me after it's merged. Maybe once or twice I've regretted this (maybe you want to backport one part of this PR to the release branch, and now you have to manually create that) but in general, how something is made can be ugly and it feels good to me to erase it when something is ready to be merged.


I'm banned from force-pushing at work so this makes jujutsu a challenge for me.

The workflow still functions, it just requires me to manually update bookmarks.


I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me.

I personally feel like your employer's policy is unusual for PR branches. Other people force pushing? Bad. Force-pushing to `main`? Bad. But force pushing to your own branch when you can delete it and re-create it? Just a waste of your time for no real reason. I wonder what the justification is.


> I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me.

Correct.

It makes sense to me because it leaves a linear history of git commits in response to comments on a PR which makes code review easier. We squash and rebase at the end.

> Just a waste of your time for no real reason. I wonder what the justification is.

We used to be on Gerrit, which I found better for code review as I could stack a bunch of minute changes together. I probably had 50-100% more productivity on Gerrit before my team made the switch.

Unfortunately, the industry standard is GitHub PRs. My team wasted a ton of time onboarding people to Gerrit and even after onboarding, less than 5% of people understood stacked changes enough to use them effectively.

Since force pushing/rebasing messes up GitHub PRs it was banned.

If you have suggestions for alternative code review workflows on GitHub I'm happy to hear them, but ideally they could be incremental.


Github's behavior when branches are force pushed makes some places ban it, that might be your parent's situation.


I guess in terms of clean workflow, I could get into that more using jj (i.e. create a PR for every bit that I want to have in the history later), but as a reviewer, I always get annoyed when I have to do a re-review of something that was force-pushed, and I'd like to avoid doing that to others. So I was kind-of hoping you had found some magical silver bullet there, haha.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: