It helps that Mercurial has a really nice cross platform GUI: TortoiseHg. Version control is one of those things that really benefits from a GUI because you're manipulating small elements complex object - the commit graph. Using the command line is bit like using ed to edit a text file (i.e. with commands like "insert xyz between lines 12 and 13").
1. I want some changes in my repo to be persistent whenever I switch to a new branch, pull, or merge a remote.
2. They should not be shown in git status.
3. They should not be pushed.
From skimming the front page I haven't found whether something like this is supported.
I see that with stgit I can `stg pop` my "persistent changes" before pushing to the remote and then apply it again with `stg push` but that requires that I use stg commands to create patches instead of `git commit`.
I did, plus MS SourceSafe, Team Foundation Source Control and Bazaar.
I don't see the problem with SVN and Mercurial. If you have merge conflicts, no tool is going to solve that.
If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merge again. Have fun solving all the merge conflicts that actually shouldn't be there.
Like I said, SVN and Mercurial are fine too. I don't see any reason why git would magically solve some merge conflict that SVN or Mercurial is not able to.
Why I should want to do it? It feels unnatural. What problem you are trying to solve by this workflow?
I'm very curious how your favorite VCS handle this case.
For this situation, at the end just do:
git rebase -i main
And delete all of the commits that you included in your squashed commit. If you want to preserve your detailed history you can create a new branch for the rebase like so:
git checkout -b mybranch-rebase && git rebase -i main
If you want Git to continue keeping track of your commits, don’t squash-merge them.
Squash merging loses valuable history in general and use of it is a sign that commits on source branches are being made carelessly.
(That said, if I had to do this, I’d rebase off of the squash before merging again and have no problems.)
Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git)
I know you have no time to know your tool. But I don't see any hurdles to allocate one evening and read https://jwiegley.github.io/git-from-the-bottom-up/. It gives a model that you can apply to other distributed VCS and may be make you a better engineer.