3 ms·

I sometimes go back and “group” commits with a ‘git rebase -i’ and squash commits that are related. Is that similar to what you’re talking about?

• 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 ago
    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.
    • pseudalopex 8y ago
      Your suggestion is more flexible, but a simple way to group commits is to preserve the original branch structure like Mercurial.