> as commit granularity is lost when they are squashed, rebased, or merged committed.
No, commit granularity is only lost when squashing. Both rebasing and merging retains all the commits.
> why not split it into multiple pull requests?
It's arguable better to have a single PR with multiple commits instead of multiple related PRs. I can review commits one by one and also see the end result, test it all together both manually and on CI/CD.
Keep in mind that having bash history is already a treat since `~/.bash_history` is readable by every program you run.
If you want to be 100% safe you could just monitor the process and see if it opens any internet connection but I am confident it is just a local program.
Poster here! ble.sh gives syntax highlighting for bash just like fish and zsh. I personally don't like zsh because it seems over engineered and fish have some design problems (I don't think they have yet fixed them).
The feature-rich alternatives you mentioned are exactly what I was thinking about (and using daily!).
There are a few things about zsh that "feel better" than bash (especially arrays), but given the ubiquity of bash, if I can get the same general quality-of-life upgrades that I experience from the zsh community add-ons, I may need to give ble.sh a go.
Edit: I gave ble.sh a try, and it is super-cool-magic, but does feel slow with quite noticeable input lag.
I agree, but we're limited by terminal emulators.
Not counting images in terminal (which can be done with a protocol few terminal supports), we don't even have Font Ligatures widely available.
No, commit granularity is only lost when squashing. Both rebasing and merging retains all the commits.
> why not split it into multiple pull requests?
It's arguable better to have a single PR with multiple commits instead of multiple related PRs. I can review commits one by one and also see the end result, test it all together both manually and on CI/CD.