3 ms·

I realized reading the first part of this article that I often want to set up a sequence of PR's, for very similar reasons as in the begininng of OP. Say, a pre

I realized reading the first part of this article that I often want to set up a sequence of PR's, for very similar reasons as in the begininng of OP. Say, a prefatory refactor, then the main work, then some data cleanup. When I do this, the problem with rebase is that it kind of breaks the additional "next in sequence" PRs "on top", or at least requires (confusing to me) cleanup in all of them when I rebase the base.

shambulatron 2y ago
Have you come across `git rebase --update-refs`? This automatically moves your "intermediate" branches during a rebase and sounds like it could be useful in your situation.
- jrochkind1 2y ago
  I have not! I'll try to check it out, thanks! The git cli still scares me when I get off the familiar path. :(
- dmurray 2y ago
  There's also `git rebase --onto`, which effectively does the reverse - you tell git you've already rebased the part of this branch that overlapped with the "intermediate" branch, and it just needs to take care of the rest.
  - Vinnl 2y ago
    Oh that sounds exactly what I need to simplify the workflow I described for the multi-PR use case. I'm going to try that out today, I just happen to have a use case for it ready to go :)
  - jrochkind1 2y ago
    Wow, I knew of neither of these, thank you! I'll have to take some time to experiment with both and make sure I understand howt hey work and any pitfalls! I am definitely in the crowd that thinks git UX is pretty unintuitive and challenging, despite having used it for over a decade! These sound like great plumbing for a github-style web UI that actually facilitates multi-step sequence PR's though...
dgfitz 2y ago
> a sequence of PR's, for very similar reasons as in the begininng of OP. Say, a prefatory refactor, then the main work, then some data cleanup. I would dislike this as a reviewer. Now I need to keep your stack of changes in my head, in order. Just make the change and push it, if people can’t review the diff you have different problems.
- jrochkind1 2y ago
  > Now I need to keep your stack of changes in my head, in order. Agreed. In another comment in this thread, I said the problem with this was "And been frustrated that Github's interface does not make it very easy to make the sequence apparent or have good DX for the reviewers." For this to work, we need better tooling support -- the reviewer having to keep track in their head is not good. I'm not sure which of the realistic alternatives you are suggesting: 1. I could submit them all as one PR. But I _know_ it's too big to review well, I needed several steps to get there. Yes, this is the "different problem", but it's normal to sometimes need to take several reviewable steps to get to the outcome, right? The OP had a very common pattern for me: Refactor with no behavior change to set the stage and make the feature easily implementable; feature implementation; data migration. 2. I could submit the PR's one at a time, and not submit subsequent ones until the first are reviewed. But now I need to keep it all in my head, which my head isn't up to, and I not infrequentkly wind up messing up my branches. AND, sticking with that common case, the reviewer doesn't see what motivated the refactor, so I have to just explain it in words, and their like "Oh but I don't like this aspect of the refactor" and I have to be like "Yeah, okay, but if you could see how I used it to implmeent the feature you'd understand why" Of course I end up doing one of these three paths (with the sequence of PR's made all at once being one of them) when this situation arises, having no other options. They are all unsatisfactory, agreed.
ants_everywhere 2y ago
Gerrit supports this workflow. Patchsets can form a "relation chain." One common workflow is you have a change of, say, 3-4 patches. You get code reviewed on them all, updating each patch set according to the reviews. Later patch sets can't be submitted until the earlier ones are. You can have tooling telling people not to review the later patch sets in the chain until the earlier ones have passed code review.

shambulatron 2y ago

Have you come across `git rebase --update-refs`? This automatically moves your "intermediate" branches during a rebase and sounds like it could be useful in your situation.

jrochkind1 2y ago
I have not! I'll try to check it out, thanks! The git cli still scares me when I get off the familiar path. :(
dmurray 2y ago
There's also `git rebase --onto`, which effectively does the reverse - you tell git you've already rebased the part of this branch that overlapped with the "intermediate" branch, and it just needs to take care of the rest.
- Vinnl 2y ago
  Oh that sounds exactly what I need to simplify the workflow I described for the multi-PR use case. I'm going to try that out today, I just happen to have a use case for it ready to go :)
- jrochkind1 2y ago
  Wow, I knew of neither of these, thank you! I'll have to take some time to experiment with both and make sure I understand howt hey work and any pitfalls! I am definitely in the crowd that thinks git UX is pretty unintuitive and challenging, despite having used it for over a decade! These sound like great plumbing for a github-style web UI that actually facilitates multi-step sequence PR's though...

dgfitz 2y ago

> a sequence of PR's, for very similar reasons as in the begininng of OP. Say, a prefatory refactor, then the main work, then some data cleanup. I would dislike this as a reviewer. Now I need to keep your stack of changes in my head, in order. Just make the change and push it, if people can’t review the diff you have different problems.

jrochkind1 2y ago
> Now I need to keep your stack of changes in my head, in order. Agreed. In another comment in this thread, I said the problem with this was "And been frustrated that Github's interface does not make it very easy to make the sequence apparent or have good DX for the reviewers." For this to work, we need better tooling support -- the reviewer having to keep track in their head is not good. I'm not sure which of the realistic alternatives you are suggesting: 1. I could submit them all as one PR. But I _know_ it's too big to review well, I needed several steps to get there. Yes, this is the "different problem", but it's normal to sometimes need to take several reviewable steps to get to the outcome, right? The OP had a very common pattern for me: Refactor with no behavior change to set the stage and make the feature easily implementable; feature implementation; data migration. 2. I could submit the PR's one at a time, and not submit subsequent ones until the first are reviewed. But now I need to keep it all in my head, which my head isn't up to, and I not infrequentkly wind up messing up my branches. AND, sticking with that common case, the reviewer doesn't see what motivated the refactor, so I have to just explain it in words, and their like "Oh but I don't like this aspect of the refactor" and I have to be like "Yeah, okay, but if you could see how I used it to implmeent the feature you'd understand why" Of course I end up doing one of these three paths (with the sequence of PR's made all at once being one of them) when this situation arises, having no other options. They are all unsatisfactory, agreed.

ants_everywhere 2y ago

Gerrit supports this workflow. Patchsets can form a "relation chain." One common workflow is you have a change of, say, 3-4 patches. You get code reviewed on them all, updating each patch set according to the reviews. Later patch sets can't be submitted until the earlier ones are. You can have tooling telling people not to review the later patch sets in the chain until the earlier ones have passed code review.