4 ms·
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 featur
by heavenlyblue 8y ago
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.
- garmaine 8y agoThere 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.
- pseudalopex 8y agoYour suggestion is more flexible, but a simple way to group commits is to preserve the original branch structure like Mercurial.