[keybored]

This is a conversation that keep repeating

- Many temp commits

- Doesn’t matter: just squash

- But sometimes I want to have a few distinct (isolated commits for my PR)

- Then make the PR small

- But I have several changes

- Then make several small PRs

We keep coming back to “just make more PRs”. Which is curious, given that GitHub doesn’t even support dependent PRs. The thing you need immediately when your PRs start depending on each other (like refactor X before implementing Y, where both touch the same code).

But I can’t come to any other conclusion than that this is because of the over-focus on PR as the one and only reviewable unit. Thanks to GitHub.

I can’t really get on the small PR train. A PR has overhead and I often want to do small changes that I only happen to notice are necessary when I am in the middle of doing that one PR.

[scott_w]

Don’t make dependent PRs. Make small PRs, review, merge and deploy them before starting the next.

[keybored]

That begs other questions. The relevant reviewer isn’t available until Wednesday. Do I start on the next tasks in dependent branches? The act of making all those branches is a large part of the inherent busywork. And then I need to remember to get back to them when the reviewer gets back.

The benefit of all these small PRs is yet to be revealed.

[scott_w]

Why are you starting work you can’t finish for days/weeks?

[keybored]

Is the dialogue here that you ask questions that makes the workflow more and more constrained and then when X factors are fixed it becomes obvious that the workflow works great?

Of course I start on work that I (not the reviewer) can work on right now.

[scott_w]

> Of course I start on work that I (not the reviewer) can work on right now.

Why do you start work you can't finish?

[CRConrad]

Who says they can't finish it???

Whateverthefuck this is, discussion in good faith it is not.