If your branch has a good number of commits since it diverged from main, rebasing can sometimes seem like a Sisyphean task. Because each commit is applied independently, you often end up resolving merge conflicts again and again in the same places, conflicts that a merge would make you resolve together in one go.
To avoid that, I sometimes squash together all the commits in my branch before rebasing on top of main. But then of course I lose the structure of the separate commits.
@BoydStephenSmithJr That "partial squash" technique sounds interesting! Is there a more detailed description of it somewhere? How does "resolving a conflict [...] to a version further down" work?
@nshephard Thanks! Although my understanding is that "rerere" mostly helps when you do repeat merges/rebases and discard the results. The docs say:
"With rerere enabled, you can attempt the occasional merge, resolve the conflicts, then back out of the merge."
In my case, I just want to perform the rebase and be done with it. The problem is merging the individual commits one by one. I dislike having to resolve the extra conflicts, even the first time!
@nshephard Actually, I've found some links that talk about rerere helping even for single rebases (?) so maybe I'm wrong. But I'm still unsure about why it would work ๐ค
When representing "subtype" relationships in #SQL, "The primary keys of subtype tables are also foreign keys, referencing the primary key of [the main table]"
