Sometimes you really don't want to look over the commit history of your colleagues. As long as it's a small feature, a single commit is a pretty good option.

Rather than:

implemented X
forgot this
oh, this was not needed
now tests actually pass
oops
fixed this
should be ready

[–] elvith@feddit.org 7 points 3 days ago (2 children)

That's basically my commit history for every repo where I need the pipeline to run to see if everything works.

[–] kungen@feddit.nu 3 points 3 days ago (1 children)

Haha same. But that's why you do it in another branch, and then squash-merge.

[–] ranzispa@mander.xyz 1 points 3 days ago (1 children)

I like squash merge on small changes, but when larger code changes are there it becomes a huge commit which is difficult to review if you ever have to go back.

[–] psycotica0@lemmy.ca 1 points 3 days ago

Right... for sure... but then if you don't want to squash, then it doesn't matter you can't squash a merge commit.

[–] ranzispa@mander.xyz 1 points 3 days ago

When I do that I always have a Dev branch that I use as the production branch to run the actual calculations.

When I get something working I merge it off, clean up the history a little bit, rebase main onto it and then rebase de onto main.

[–] expr@piefed.social 3 points 3 days ago

It's fine if the changes belong in a single commit. Otherwise, an interactive rebase to craft a clean, quality history before merging is much, much better.