stop making giant changesets!

I wish memes could be posted in here because I need to post that green guy looking to the side

I guess this works well with a big code like sentry but would create too much overhead with smaller teams. Any advice for this case?

Could you make use of: git commit --fixup <commit to fix> and git rebase --autosquash on the mega MR and then update the small MRs via cherrypick

Would be interesting to hear a comparison to this approach, if it ends up being meaningfully different or not

I love the idea of splitting your code into multiple PRs! You should switch to `git switch`! Also, here's a git alias I use all the time that you might like: remaster = !git fetch && git rebase origin/master

I can see that we have an index (mega branch) and then the branches that we create to push to remote for reviews. However, when you’re first fleshing out the code, before breaking it into logical units are you still using the mega-index for that?

Also, I was wondering about how to break up commits with a feature and its corresponding tests. Tests can take up a lot of lines themselves and we can’t have a feature released without all its required tests first right? How do you break those kind of PRs into smaller ones?

Interactive rebase is a king of atomic patches👍

I totally hear you! I have trained myself to keep changes smaller. It’s so much easier to review and keep people close to the main branch.

Agree on breaking up work into smaller bits, but personally I don't like having to rebase. What would be the drawback of having a feature branch instead where every commit must be added via a (small) PR?

For "first" commits introducing a feature, would each commit instead then be a logical atomic necessary for the feature's implementation? Still feels like a logical atomic could easily exceed 200 lines at times

Frankly this looks like pain, 100-200 LOC should be easy to review and 13 commits just makes it more annoying for both the writer and the reader

I agree that the github (same with gitlab) diff looks cluttered and like pure chaos, but it's just a shit UI, often compounded by bad diff region highlights, a nice vscode setup with side by side files is just so much better

Also, I'm really curious how you'd tackle a migration/updating breaking dependencies (in the range of 90k lines before the code even compiles). <100 line commits would be unmanageable IMO

To be clear, if it works for you, that's great! but the video leaves me with more questions than answers when thinking about how to apply it

Two minutes in and I'm surprised CI/CD wasn't mentioned yet

Interesting approach! I love atomic commits and rebasing workflows but I never thought also about doing atomic PRs. As a reviewer, I don’t know if I’d find it easier to review 13 separate PRs vs a relatively small one with 13 commits. I guess it depends how related the changes are. In the small PR I can always just look at the diff of each individual commit anyway, so I feel I’m missing something 🤔. I guess your approach works well for a team where there’s more than just a few reviewers, so those 13 PRs won’t be reviewed by the same 1/2 people.

GH has now an interface to make reviews by commits, although it is worst than GL's one, it allows you to make review comments and stuff, so it's OK.

"I started by removing this hack that I put in"... yup love it!

Sometimes one just can't avoid massive changesets ... Like when I change aiosmtpd's test harness from "nose" to "pytest", it was thousands of lines of change, because all unit tests need to be rewritten.

But afterwards changes are mostly small sized.

If this workflow does not have a name I would call it the "async octopus" because this is basically an "octopus merge" but where all the branches are merged sequentially rather than all at once.

👏👏👏

Maybe worth expanding on what you mean by "rebase workflow"

What would you do if you were working on a new feature?
Adding models, new views, new graphql queries, etc. I ask this because I have this problem a lot and completely agree in the smaller reviewable changes, however If I just base the graphql code on top of the models, at the end ill have to merge and show a huge changelog off main branch