Programmer Humor

19821 readers

222 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

Keep content in english
No advertisements
Posts must be related to programming or programmer topics

founded 2 years ago

MODERATORS

[email protected]

423

git commit -m "minor fixes" +26858 -69429 (feddit.de)

submitted 11 months ago by [email protected] to c/[email protected]

72 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

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

We are mortal enemies you and I 😄 I'd much rather have a descriptive commit history than huge commits which make git blame meaningless. Function over beauty for me.

CC BY-NC-SA 4.0

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

A nemesis! I'm pretty lucky I guess that no one at my workplace has strong git opinions that differ

Do you have multiple people's commits being squashed together? Or how is blame being made useless for you? I'm at a rather small company where generally it's just one person working on a thing at a time. The blame will point to their squashed commit that, if they wrote a good message like the top of this thread, will give you a lot of context.

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

Imagine finding a bug in angularjs, doing a git blame and finding this commit

feat(module): new module loader

211 changed files with 1,051 additions and 1,242 deletions.

AngularJS isn't even the worst offender. I've seen backports of multiple fixes getting squashed into one commit for "a clean history" with all the useful commit messages ending up in one commit.

Many user stories I've seen implemented in a sprint take multiple days to write. Sometimes they have 5+ commits with a multitude of files changed and (if done right) each commit has an explanation why something was done or at least what was done. Having a granular view of changes also allows finding related changes quickly with less code to read.
If someone changes the implementation of a function call in one commit and it introduces a bug, it's nice to have only that change instead of the entire class with it and changes in other files too. Additional changes mean now you have to read through more code to be sure that the function implementation change was not done due to a modification of the class or whatever else was changed which might be the actual source of the problem.

IMO squashing commits has its uses. It's a tool in a toolbox, but it's not the only tool.

CC BY-NC-SA 4.0

[–] [email protected] 2 points 11 months ago

That angular commit message is a crime.

My squashed commit messages typically enumerate everything I changed and why.

IMO squashing commits has its uses. It’s a tool in a toolbox, but it’s not the only tool.

I think we agree on this.

One case that has come up for me several times: working on a feature, committing as I go. And then I realize some of what I did won't work or isn't what product actually wants. Leaving those commits in the history that show the function doing the wrong thing would be misleading. Especially if that was never actually in production or left my local machine.

I guess I have an unspoken belief that every commit on main should work, but you could achieve that with tags instead.

I was recently spelunking to try to find why something in old code was the way it was. I found the commit where they changed the line, but it was orphaned from the larger context. The message didn't say more than like "change field from footype to bartype", but not why. So I had to try to piece together what other changes were part of this change. If it had been a single commit that showed them like adding the new field, new model, and whatnot, it would have been clearer to me that those things all go together.