"How does revup work" series

[jerry-skydio]

Several revup features have interesting implementations and would benefit from a deeper dive explaining how they work.

[positron]

More docs would be awesome.

Beyond features, some minor workflow things that weren't clear to me at all as a new user (and still really isn't tbh):

• do most people do their revup commits on main or on feature branch(es)?

• Is there an easier workflow for rebasing when the PR merge squashes commits. For example, run revup upload on HEAD - A - B- C, three topics, three PRs. Now C is approved, PR feedback on A means the commit chain is now C/HEAD - A - B - A-feedback. When I hit the "Squash and Merge" button on Github and then rebase I have to manually untangle some stuff. I think this is probably intrinsic to git though.

[jerry-skydio]

• I generally work on main, and I would say most people do as well, but I think it depends on your local changes. There may be cases where I'm working on a set of changes thats WIP or otherwise disruptive enough that I'd want them on a feature branch to not interfere with testing topics on my main branch.

• unfortunately this is a reality of how git deals with squashes. I personally don't like "squash-on-merge" for this reason and because it also breaks other features of real merges. One option is that you ask your repo maintainer to turn off squash on merge and either use "real merges" or "rebase on merge". The other option is for you to keep all your PRs to a single commit, then use "revup amend" to squash "A-feedback" into "A" before uploading

[positron]

👍 thanks

I've settled on that exact pattern as well. main unless it's something disruptive or experimental.

I've also settled on using revup amend for the second workflow.