[Lldb-commits] [lldb] [lldb] refactor highlighting function for image lookup command (PR #76112)

[David Spickett via lldb-commits]

DavidSpickett wrote:

> Do you think the commit message is good enough?

The commit spends a lot of time talking about the previous PR not saying what this PR does. "Follow up to #..." is enough to give context.

This PR puts all the highlighting settings into a single struct for easier handling. That's what the commit message should tell us.

> Also, kind of a git question: is it better to wait this PR conclude to open the next since there will be concurrent modifications in basically the same files?

So you're asking about "stacked PRs" and I myself haven't tried this. LLVM has recently enabled user branches on llvm/llvm-project so I think it is possible using some of the tools out there, but I have not tried it. I would look on the forums for anyone who's tried it, or ask on Discord for advice.

A half way point that you can do, is to have a local branch that has changes for many PRs on it. Then make a branch that only includes the changes meant for the first PR. Push that into review and in the meantime, you can continue to work on the larger branch. When the PR lands, rebase the larger branch onto `main`, and make another sub branch for the next PR, etc.

```
all_changes:
C
B
A
main

<make a new branch with only A changes on main>

all_changes:
C
B            first_pr:
A            A
main         main

<push first_pr for review>
<PR is approved>
<PR landed onto main>
<rebase all_changes>

all_changes:
C
B
main
```

This is what I've been doing, it's got its own problems and if someone wants to see the whole stack, you'll have to push `all_changes` to GitHub also (but for me doing open source work only that's fine). Also I have decent luck with fast reviews, or am doing work where it needs in depth review, so it works out for me.

If you have 10 small changes to make and your reviewer is in the opposite time zone, stacked PRs can be a great benefit as the reviewer can look at all 10 in one session so the feedback is ready for your next working day.

Either method involves some amount rebasing and conflict resolution.

https://github.com/llvm/llvm-project/pull/76112