alt Hacker NewsI’m doing rebasing a lot these days, especially since I started using gh stack. The main struggle I have with rebasing is for git to recognize that a branch has actually been merged when its commits have changed (e.g., if I forgot to delete the local branch with old commits and come back months later and trying to figure out if it was actually merged or not). My understanding is that this is nicer with jj when you work locally, but if you sync with GitHub, I think your still faced with the same problem, or?
What are people doing to workaround this? I’ve tried to ask LLMs, but the complexity is frankly a bit off putting (I don’t have the suggestions handy)
Don’t you have an id system, like an issue tracker? That’s your source of truth for change requests.
The common advice is to never have long standing branches for WIP. But if you do, squash it to have a small number of commits, then replay it on top of the default branch. The try to understand why there’s any diff or conflict (refactor, update to the design, code removal, was not merged at all,…). As I squash merge, I always remove the PR branch from the main repo. And I keep it for about a week on my local repo (In case the PR is reverted and I needed my drafting version of it).