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.
@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!
@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?
It seems that, if you want to check for some value-level condition when matching, you need to bring in ViewPatterns. This is mentioned in the wiki but not (explicitly) in the GHC user guide.
When representing "subtype" relationships in #SQL, "The primary keys of subtype tables are also foreign keys, referencing the primary key of [the main table]"
Not sure why trailing commas aren't more common in programming languages and formats. Does it make the parser simpler? Can't imagine. (current example: #haskell)
