@Quantenteilchen@discuss.tchncs.de
Post #1812231
2026-04-30 06:29 UTC
Replies (4)
-
@ranzispa@mander.xyz 2026-04-30 07:31
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
-
@mcv@lemmy.zip 2026-04-30 08:26
I’m not a fan of changing history in general. Rebase can also he dangerous. I think ultimately it’s a matter of scale. Sometimes it can be useful to look into the details of the development of a single feature, but in a large project, that rarely happens. I’m not a fan of squashing, but for large projects, it helps to keep your history manageable.
-
@psycotica0@lemmy.ca 2026-04-30 12:41
Yeah, I’m with you. I mean, git isn’t magic. You “can” squash anything, including a merge commit, but just being at the end result, running git reset and then running a manual git add and commit there. That’s basically all a squash is. But what you’ll be left with us a single commit that contains all of the code from the branch you’re squashing and also all the code pulled in from every branch you merged, all written as though it all came from this one commit. And maybe that’s what you want? But it feels like also maybe it’s not?
-
@kevincox@lemmy.ml 2026-04-30 22:53
I think it doesn’t really make sense. Because you can’t “squash” one commit. squash is taking multiple commits and making them one. When you do a “squash merge” you are really saying “squash all the commits that are on this branch and not the target” then merge. So you can’t “squash a merge commit” you need at least one additional commit to squash in.