I don't mind merge commits, it's the 100 tiny individual commits some developers seem to like to do that really clutters things up. Yes, I know, git squash is a thing, but not committing until the feature is working and ready to commit is also a thing.
> not committing until the feature is working and ready to commit is also a thing
That leaves you prone to losing work if you have a false start that you need to back out of. I prefer to commit early and often on my private branches, then before submitting a pull request I clean up the history to where there are a few good commits that form useful, standalone chunks (ideally the test suite fully passes on each commit).
>That leaves you prone to losing work if you have a false start that you need to back out of.
Hasn't happened to me in over 20 years of using version control. I always keep moving forward, there's really never been a need to go back to a previous commit that hitting crtl-Z wouldn't accomplish just the same. If I wanted to try a new direction I'd just clone the repo again and do the work there. Littering the git history with dozens of superfluous commits just seems pointless. Having to stop and think about writing a commit comment is also just a waste of time - in aggregate it wastes a lot of time. It adds a lot of churn to a workflow for something that may never really be of any value.
> Littering the git history with dozens of superfluous commits just seems pointless.
This is where the final rebase comes in—you should be combining all the small commits into one.
> Having to stop and think about writing a commit comment is also just a waste of time
Most of my commits when I'm working like this are named "draft". The names don't matter when you're going to redo the history later.
> I always keep moving forward, there's really never been a need to go back to a previous commit that hitting crtl-Z wouldn't accomplish just the same.
You've never started down one path for solving a subproblem only to realize 30 minutes in that it's not going to work?
>This is where the final rebase comes in—you should be combining all the small commits into one.
Sorry, but I'm a software engineer, not a git engineer, and the less I have to do with git, the better. KISS applies to git, too. A simple thing like not creating a commit for every stupid thing keeps the history clean, doesn't bog down the developer by requiring to think about writing a commit message every 2 minutes, and keeps git simple.
>Most of my commits when I'm working like this are named "draft". The names don't matter when you're going to redo the history later.
But then what value have you added by naming everything "draft" and creating a commit? There is no value in doing this.
>You've never started down one path for solving a subproblem only to realize 30 minutes in that it's not going to work?
Sure I have, but I don't need to enter it into the git logs. I'll either start over in a clone of the repo if I want to save the bad work for whatever reason (which is very unlikely), or I'll just stash the work, or whatever. The thing I don't need to do is commit the bad work.
