this post was submitted on 04 Apr 2024
1113 points (98.1% liked)

Programmer Humor

19817 readers
65 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 16 points 8 months ago (1 children)

I used to only merge. Now I rebase. The repo is set up to require squash and rebase when going to main.

All the garbage "spelled thing wrong" and "ran formatter" commits go away. Main is clean and linear.

[–] [email protected] 1 points 8 months ago (1 children)

Squash and rebase or squash or rebase?

[–] [email protected] 6 points 8 months ago (2 children)

..and? You squash so all your gross "isort" "forgot to commit this file" "WIP but I'm getting lunch" commits can be cleaned up into a single "Add endpoint to allow users to set their blah blah" comment with a nice extended description.

You then rebase so you have a nice linear history with no weird merge commits hanging around.

[–] [email protected] 1 points 8 months ago (1 children)

Okay honest question, when you merge a PR in GitHub and choose the squash commits box is that "rebasing"? Or is that just squashing? Because it seems that achieves the same thing you're talking about.

[–] [email protected] 3 points 8 months ago (2 children)

There's two options in the green button on a pr. One is squash and merge, the other is squash and rebase.

Squashing makes one commit out of many. You should IMO always do this when putting your work on a shared branch

Rebase takes your commit(s) and sticks them on the end.

Merge does something else I don't understand as well, and makes a merge commit.

Also there was an earthquake in NYC when I was writing this. We may have angered the gods.

[–] [email protected] 1 points 8 months ago

Lmao I'm in the NYC area and my whole house shook. I'm right there with you. Thanks for the explanation!

[–] [email protected] 0 points 8 months ago (1 children)

You should IMO always do this when putting your work on a shared branch

No. You should never squash as a rule unless your entire team can't be bothered to use git correctly and in that case it's a workaround for that problem, not a generally good policy.

Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.

Rebase "merges" are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn't. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.

[–] [email protected] 2 points 8 months ago (1 children)

I don't want to see a dozen commits of "ran isort" "forgot to commit this file lol" quality.

Do you?

Having the finished feature bundled into one commit is nice. I wouldn't call it stupid at all.

[–] [email protected] 1 points 8 months ago

Note that I didn't say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.

[–] [email protected] 1 points 8 months ago

You squash so all your gross "isort" "forgot to commit this file" "WIP but I'm getting lunch" commits can be cleaned up

The next step on the Git-journey is to use interactive rebasing in order to never push these commits in the first place and maintain a clean history to be consumed by the code reviewer.

Squashing is still nice in order to have a one-to-one relationship between commits on the main branch to pull requests merged, imo.