@sir that was a very good synopsis with some awesome real world advise. I need to follow the not sneaking little changes in with other commits more closely.

I don't like history editing in git. I favor how fossil-scm has a permanent history.

But then..... Bazaar and Cathedral arguments ensue.

@cobra2 but really you should learn to embrace history editing in git. The ivory tower concept of history as an immutable truth is insufferable. If editing your history makes version control more useful to you, then why wouldn't you do it?

Like @sir mentioned, I wouldn't edit something in my stable or release branches, but it makes sense to clean up your history before it goes out to the rest of the team or the rest of the world.

I find myself doing a lot of reorganization of commits—rebasing, cherry picking, all sorts of editing—before merging into long-term or important branches.

@sir @cobra2
I consider it similar to submitting a paper. When I'm at my desk, I can work more effectively if I don't have to worry about making it perfect the first time.

It's only once I'm certain of my content that I clean it all up, bind it nicely, etc.

@sir an alternative to the "fixup" commit followed by a rebase is to stage the changes and then do 'git commit --amend', which is arguably less work.

@melentye that only works if the last commit is the one that needs fixing

Sign in to participate in the conversation

cmpwn.com is a private Mastodon instance for friends of SirCmpwn.