pulsar-edit
Merge back master into updated-latest-electron
Seems like a "process of how we work with these branches" PR as opposed to a strictly code-focused PR.
@savetheclocktower has been cherry-picking from master, this merges from master.
I dunno if it is necessary from a "syncing the code" perspective, but it might clarify the relationship of the branches from a revision history/version tracking (lower-level git-isms) perspective? Effectively marks how much diff we want to yeet vs master and what we want to confirm is desired, and let git understand such explicitly...
But the real thing is whether to be doing merges or cherry-picks, I think that should be down to the preferences of active contributors to this branch IMO. If there's, say, @savetheclocktower (preferring cherry-picks?) and @mauricioszabo (preferring merges?) that's a tie and I dunno.
But maybe a chat on the Discord could clear up how to handle history divergence (cherry-picks or merge commits) in the future for this work ??
(I don't think it makes sense to scrutinize this PR's diff closely without resolving that larger-picture question.)
Maybe this will put everyone's mind at ease: updated-latest-electron is never going to get PR’d against master.
When we're ready (or nearly ready) to ship Pulsar on Electron 30, I'll create a new branch off of master. I'll use the diff between updated-latest-electron and master as a reference and a target to reach, but I'll recapitulate the changes in a much more logical series of commits. (One commit for removing legacy Tree-sitter, one for updating pathwatcher, etc.) When that candidate branch has zero diff with updated-latest-electron, it'll be suitable for landing.
In the meantime, rest assured I'm keeping this branch up to date.
Since we determined that 99% of the differences in this PR are purposeful, I'm closing this one. We've got an Electron 30 release candidate in PR and we can revisit this PR’s diff if we think anything got missed in #1367.