There's a wonderful thing that we used to have and still do have, but might be going away soon. It's called "terrestrial television". For decades people streamed programming over the airwaves, straight off the antenna! For free! Ad-supported of course, but... no tracking! (Actually opt-in tracking with a Nielsen People Meter.)
> Maybe the truth is that it does not take 7 months, but 7 years?
Yes, that is the truth. I run a business solo and it takes a long time to get to the point where you're making decent income, because running a business has its own costs, and those costs scale as you scale, so it never feels like "enough" until it finally does. I personally do believe in the whole "build and they will come" bit, but the 'coming' part is on the order of years, not weeks or months, and it's a slow linear trickle, not an exponential curve like the talking heads like to tout. Of course, you do have to build something people actually want, and something those people will actually pay for, but your number one goal should simply be Don't Die. Live long enough so that people know you exist, carve out a little niche for yourself, and fight for that linear trickle until it's "enough."
Not really. Without seeing the entire changeset for a PR, you'd have to mentally keep track of what the current state of everything is unless you're a commit minimalist and presquash.
If we're speaking strictly code review, because you can actually make sense of the changeset for the child PR by not including its unmerged parent's changeset.
I must have missed that. Amazing! From a reviewer's POV, this will be so nice to at the very least remove diff noise for PRs built on top of another PR. I usually refrain from reviewing child PRs until the parent is merged and the child can be rebased, for the sole reason that the diffs are hard to review i.r.t. what came from where.
Stacked PRs can be created via the UI, API, or CLI.
You can also run a combination of these. For ex, use another tool like jj to develop locally, push up the branches, and use the gh CLI to batch create a stack of n PRs, without touching local state.
CLI is great because now I can tell my AI agent to do it. “Fix all dependabot security issues (copy logs) and run tests to validate functionality. Create each dependency as its own stack (or commit) so that contributors may review each library update easily.”
Everyone will have their own way of structuring stacks, but I've found it great for the agent to plan a stack structure that mirrors the work to be done.
My point is that Git is just a component of the GitHub tool, and the GitHub CLI is quite good and helps automate many things in GitHub. For example, even just using `gh browse` and `gh pr create --web` and `gh pr view --web` are fantastic tools.
I don't need to automate anything in GitHub, I have a web browser for when I need to use GitHub. Installing and learning another CLI seems like a waste of my time for very, very little return.
You would rather manually browse to the repo you're working on in the web interface rather than typing `gh browse`? I hate CLIs, in general, but the GitHub CLI has some very useful commands.
reply