I See a Future in Jj

Re:I See a Future in Jj by jrockway on Thursday October 23, 2025 @04:57PM (#45687023)

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.

[ Parent | on HN ]

Re:I See a Future in Jj by steveklabnik on Thursday October 23, 2025 @08:40PM (#45689362)

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

[ Parent | on HN ]

Re:I See a Future in Jj by jjmarr on Thursday October 23, 2025 @08:42PM (#45689381)

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

[ Parent | on HN ]