I think the issue (which seems to exist in pretty much every VCS out there) is that there is a single flat timeline - even with branches (assuming they aren't treated as just separate parts of the tree) you get a single timeline per branch at best.
Wouldn't it be better to be able to "nest" or "group" commits so that, e.g. all the "intermediate" commits go under the final commit which is what is displayed by default and "traveled" through via tools like log, blame, etc?
Right now the best (though really not solving the issue) is to have a branch per task for VCSs where branching is trivial but this doesn't really solve it since you still get all the commits in your history anyway (i think some clients can display only the merge, but this is up to the tool, not an inherent feature).
There was the other day a submission about a project on github where people noticed that the git history looked as if the author was making a new commit automatically every time he saved a source file and most comments were about how bad that it was. And i was thinking "Why? The issue here is that you can see those commits, not that they exist".
You could easily have something like
* Feature #1 submission
* Feature #2 submission
* Quick prototype hack
* Save at 12/13/14 09:30
* Save at 12/13/14 09:31
* Save at 12/13/14 09:41
...
* Attempt #1
* Save at blahblah
...
* Attempt #2
* Save at blahblah
...
* Final Fix
* Save at blahblah
...
* Bug fix for #8923
* Attempt #1
* Review update
* Etc
and by default in the timeline/log you'd only see the top three commits until you drilled down, even to automated ones from file saves. Similarly when you looked at "blame" (or whatever) you'd see these commits. And of course all these tools should have a "max depth" (default 1) to allow you go into more detail. And yeah, you'd also need some functionality to specify and edit (preferably with its own history - Fossil already does that for other stuff like wiki) the parent/child relationships, perhaps with some current state (ie. under which commit all new commits will be placed).
With something like that in place i do not see any reason to not keep as much as possible around.
I've been testing out a new workflow I'm Git in some personal projects that basically works like this.
Basically, I make a single wip branch, which contains all of my messy/frequent commits, then when I feel that things are in a good state and I'm ready to cut a release off that branch, I tag that commit with "wip-vX.Y.Z".
Separately, there is a "release" branch (which is basically master/main/trunk) that only ever gets code that was first committed into wip. When there's a new release tag in the wip branch, I run the following command on the release branch: "git cherry-pick -X theirs -n wip-vA.B.C..wip-vX.Y.Z", where A.B.C is the tag of the previous wip version and X.Y.Z is the tag of the current new wip version. This has the effect of taking all of those changes from the wip branch and staging them to be committed on the release branch. I then commit them with a descriptive commit message and tag that commit "release-vX.Y.Z".
What you end up with, as a result, is a "release" branch with a very clean commit history and a "wip" branch with a very detailed commit history. If you want to run a more detailed blame or bisect, all you need to do is checkout the "wip" branch. If you want to use code that's stable enough to be called a release, all you need to do is checkout the "release" branch. Rather than squashing/amending wip commit history out of existence or maintaining on a series of scattered branches, this workflow makes it all conveniently available in one place, without directly polluting the main branch.
As for the wip commits themselves, I do try to have them all be mostly atomic and to have them always build. But I feel much less concerned with having a couple of commits that try some idea then a couple more later on that undo it. Polluting a main branch with these sort of no-ops has never seemed particularly appealing to me, but not has simply deleting them, or tucking them away somewhere difficult to find. I've only been using this new workflow for a couple of weeks, but so far it seems to solve that problem and in general be working great.
Wouldn't it be better to be able to "nest" or "group" commits so that, e.g. all the "intermediate" commits go under the final commit which is what is displayed by default and "traveled" through via tools like log, blame, etc?
Right now the best (though really not solving the issue) is to have a branch per task for VCSs where branching is trivial but this doesn't really solve it since you still get all the commits in your history anyway (i think some clients can display only the merge, but this is up to the tool, not an inherent feature).
There was the other day a submission about a project on github where people noticed that the git history looked as if the author was making a new commit automatically every time he saved a source file and most comments were about how bad that it was. And i was thinking "Why? The issue here is that you can see those commits, not that they exist".
You could easily have something like
and by default in the timeline/log you'd only see the top three commits until you drilled down, even to automated ones from file saves. Similarly when you looked at "blame" (or whatever) you'd see these commits. And of course all these tools should have a "max depth" (default 1) to allow you go into more detail. And yeah, you'd also need some functionality to specify and edit (preferably with its own history - Fossil already does that for other stuff like wiki) the parent/child relationships, perhaps with some current state (ie. under which commit all new commits will be placed).With something like that in place i do not see any reason to not keep as much as possible around.