433
top 50 comments
sorted by: hot top controversial new old
[-] canpolat@programming.dev 70 points 10 months ago
[-] idunnololz@lemmy.world 11 points 10 months ago

Meanwhile I'm like

[-] Thorry84@feddit.nl 56 points 10 months ago

I've seen a changelog that said "Introduced some bugs, so we can fix them later".

It was a joke, but true nonetheless.

[-] pressanykeynow@iusearchlinux.fyi 7 points 10 months ago

It was a joke

Narrator: Of course, it wasn't.

[-] vbb@lemmy.world 52 points 10 months ago

Good opportunity to say how annoying are update notes like “We are continuing to improve our application. We fixed a couple more issues to make it more stable”. Corporate style, uselessness and the fact that this update can contain some stupid redesign is disgusting.

[-] TurtleTourParty@midwest.social 11 points 10 months ago

"We are constantly improving our application. Please keep updates turned on."

[-] popcar2@programming.dev 7 points 10 months ago

I've reached a point where I avoid these types of updates. An update post like that either means nothing important changed or they're up to something.

A while ago I saw that style of patch notes, updated an app, and suddenly I can't use it anymore because it got limited to a maximum of 2 devices. Another time I updated an app putting a harmless "we improved the user experience" message, they put dark mode behind a paywall. This isn't counting the number of times an app got redesigned to make the user experience worse for no reason. Maybe they wanted to justify hiring 5 UI/UX interns in that quarter or something.

The patch notes look harmless, but my god, they are usually up to something.

load more comments (1 replies)
load more comments (2 replies)
[-] cali_ash@lemmy.wtf 46 points 10 months ago* (last edited 10 months ago)

Yep, we also got one of these:

and pretty sure the "y" was typo.

[-] 4am@lemm.ee 33 points 10 months ago
[-] MajorHavoc@programming.dev 8 points 10 months ago

We have the best commit log in the world, because of jail.

[-] Flipper@feddit.de 6 points 10 months ago

Could be worse. I've got a repo where 30 commits after eachother are just ".". Nothing else.

load more comments (1 replies)
load more comments (1 replies)
[-] ryannathans@aussie.zone 31 points 10 months ago

The people that do this are either inept or experts, no inbetween

[-] funkless_eck@sh.itjust.works 3 points 10 months ago

just a hobbyist here, but wouldn't this actually be a good use for AI? Just copy the code and "provide a git committ title for this code"?

[-] ryannathans@aussie.zone 7 points 10 months ago

AI might be able to write what you did but not why you did it

load more comments (1 replies)
[-] kubica@kbin.social 31 points 10 months ago* (last edited 10 months ago)

My personal favorite used to be "Long time no commit"

[-] Croquette@sh.itjust.works 9 points 10 months ago

I call that a checkpoint when I do it. But I do that on my branch that will eventually be squash merged.

[-] MajorHavoc@programming.dev 6 points 10 months ago

I like to go for dark jam poetry, in those commits.

'why is anything? can it be? desolation - oh wait, that variable is mistyped!'

[-] kaotic@lemmy.world 29 points 10 months ago

Every one is using AI to make funny pictures. This is what they should be using it for. Look at my diff, generate a commit message.

[-] andnekon@programming.dev 14 points 10 months ago

If you don't know what you've done within a commit, it probably shouldn't be a single commit, with or without AI Although if you're talking about using AI to make funny commit-messages...

load more comments (2 replies)
load more comments (1 replies)
[-] jjjalljs@ttrpg.network 25 points 10 months ago

My commits when merged into main generally read like

[Ticket-123] Summary of what was done. Eg: Return user foo property in bar endpoint

  • update bar view to return new foo key
  • update foobrinator to determine foo property
  • update tests

It takes an extra minute or two but it's more informative for the team / future me.

[-] onlinepersona@programming.dev 3 points 10 months ago

Mine look similar except the body is mostly "the X was doing Y, but it should've been doing Z" or "the docs say bla, $link". I try to separate the individual "update A to do B" in separate commits, but sometimes it just isn't possible.

CC BY-NC-SA 4.0

[-] jjjalljs@ttrpg.network 3 points 10 months ago

We squash everything (and rebase rather than merge) so I don't worry much about the individual commits. I like that main is pretty concise and doesn't have a ton of work-in-progess stuff in the log.

[-] onlinepersona@programming.dev 4 points 10 months ago

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

[-] jjjalljs@ttrpg.network 3 points 10 months ago

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.

[-] onlinepersona@programming.dev 5 points 10 months ago

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

load more comments (1 replies)
[-] catlover@sh.itjust.works 23 points 10 months ago* (last edited 10 months ago)

git commit -m 'initial commit'

git commit --amend

git commit --amend

git commit --amend

git commit --amend

....

git commit --amend

[-] Sage1918@lemmy.world 3 points 10 months ago

It's all fun and games until a git push slides in between...

[-] EmergMemeHologram@startrek.website 4 points 10 months ago

Always use --force, far fewer errors that way.

I also use git reset instead of merge. It keeps history more linear.

load more comments (1 replies)
[-] neurospice@lemmy.dbzer0.com 22 points 10 months ago

Could be worse:

git commit --allow-empty-message -m ""
[-] cupcakezealot@lemmy.blahaj.zone 22 points 10 months ago

kinda like on google play how it says "what's new: no information from the developer" or "what's new: we regularly update our app to fix bugs, improve performance and add new features".

[-] lambdabeta@lemmy.ca 21 points 10 months ago* (last edited 10 months ago)

All praise our lord and saviour git rebase -i!

load more comments (3 replies)
[-] marcos@lemmy.world 9 points 10 months ago

And I'd bet stuff is still broken!

[-] MajorHavoc@programming.dev 7 points 10 months ago

Yeah. Definitely. If it was fixed there would be a commit with log 'works now. WTF?!'

[-] Cwilliams@beehaw.org 9 points 10 months ago
do_the_thing() {
  git commit -am "$(date)"
  git push
} 
[-] bitwolf@lemmy.one 7 points 10 months ago

Maybe they tastefully squash merge when they pr/merge into main.

load more comments (1 replies)
[-] ConstantPain@lemmy.world 7 points 10 months ago

At least none of it is WIP...

[-] Buttons@programming.dev 6 points 10 months ago

Meh. At least you know "WIP" means you shouldn't expect that particular commit to work.

[-] ConstantPain@lemmy.world 3 points 10 months ago

It just has to work enough.

[-] oeLLph@feddit.de 3 points 10 months ago

There are some, but not in the picture 🙃

[-] ryannathans@aussie.zone 2 points 10 months ago

Perhaps, but there will a bunch of TODO comments so pick your poison

[-] Justas@sh.itjust.works 3 points 10 months ago

I remember making a bunch of fixes and calling them after Star Wars movies with the thing I'm fixing or what was broken as the noun.

load more comments (5 replies)
[-] oeLLph@feddit.de 3 points 10 months ago

Why user standard version and conventional commits in the first place? When this is only a fraction of purposeful commit messages

load more comments (3 replies)
[-] TxzK@lemmy.zip 2 points 10 months ago

Commit messages of my personal projects are filled with just "fix". Life is too short to write a proper commit message

load more comments
view more: next ›
this post was submitted on 15 Jan 2024
433 points (97.8% liked)

Programmer Humor

19623 readers
1 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 1 year ago
MODERATORS