No, I believe what author is asking for is to keep those changes in git, but have git manage grouping of history logs for you.

E.G. you have worked in a feature branch, and committed 10 times - let those commits be kept in the log, but when running git log there must be a flag that allows for filtering based on how granular the output must be.

That can be done with rebase, but then you loose history.

I am pretty sure you can implement something like that in git based purely on commit message content.

There is no theoretical reason you can’t maintain two histories—-e.g. when rebasing have a “rebase-merge” commit that has the hash of the other tree, and optionally keep that history around in the git repo. Then you could do a ‘git blame —orig’ or whatever to switch between immutable and cleaned up history.

No VCS I’m aware of supports this. But they COULD.