- canpolat ( @canpolat@programming.dev ) English53•6 months ago
- Thorry84 ( @Thorry84@feddit.nl ) 41•6 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 ( @pressanykeynow@iusearchlinux.fyi ) 5•6 months ago
It was a joke
Narrator: Of course, it wasn’t.
- Ashy ( @cali_ash@lemmy.wtf ) 29•6 months ago
Yep, we also got one of these:
and pretty sure the “y” was typo.
- 4am ( @4am@lemm.ee ) 22•6 months ago
Straight to jail
- MajorHavoc ( @MajorHavoc@programming.dev ) 6•6 months ago
We have the best commit log in the world, because of jail.
- Flipper ( @Flipper@feddit.de ) 5•6 months ago
Could be worse. I’ve got a repo where 30 commits after eachother are just “.”. Nothing else.
- Ashy ( @cali_ash@lemmy.wtf ) 1•6 months ago
More than anybody I’d like seeing justice be done.
Be we need him, he fixes our javascript …
- TurtleTourParty ( @TurtleTourParty@midwest.social ) English1•6 months ago
I was hoping one would be nae nae
- ryannathans ( @ryannathans@aussie.zone ) 24•6 months ago
The people that do this are either inept or experts, no inbetween
- kubica ( @kubica@kbin.social ) 23•6 months ago
My personal favorite used to be “Long time no commit”
- MajorHavoc ( @MajorHavoc@programming.dev ) 2•6 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!’
- Eevoltic ( @neurospice@lemmy.dbzer0.com ) English20•6 months ago
Could be worse:
git commit --allow-empty-message -m ""
- Lambda ( @lambdabeta@lemmy.ca ) 17•6 months ago
All praise our lord and saviour
git rebase -i
!amen!
- JATtho ( @JATtho@sopuli.xyz ) 1•6 months ago
I fckd up a
git rebase -i
today withgit commit -a --amend
…Thankfully
git reflog
allowed me to assemble the branch again … from pieces.
- jjjalljs ( @jjjalljs@ttrpg.network ) 15•6 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 ( @onlinepersona@programming.dev ) English4•6 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.
- jjjalljs ( @jjjalljs@ttrpg.network ) 2•6 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 ( @onlinepersona@programming.dev ) English4•6 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.- jjjalljs ( @jjjalljs@ttrpg.network ) 2•6 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 ( @onlinepersona@programming.dev ) English6•6 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.
- jjjalljs ( @jjjalljs@ttrpg.network ) 2•6 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.
- katy ✨ ( @cupcakezealot@lemmy.blahaj.zone ) 13•6 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”.
- Cwilliams ( @Cwilliams@beehaw.org ) 9•6 months ago
do_the_thing() { git commit -am "$(date)" git push }
- bitwolf ( @bitwolf@lemmy.one ) 5•6 months ago
Maybe they tastefully squash merge when they pr/merge into main.
The don’t… 😭
- Solivine ( @solivine@sopuli.xyz ) 3•6 months ago
When there’s a limit to the size of a commit message it does make it difficult to actually list all the changes, so sometimes this is all you can write.
I know in theory you’re meant to commit little and often, but in practice it doesn’t always work out that way.
Why user standard version and conventional commits in the first place? When this is only a fraction of purposeful commit messages
- CubitOom ( @CubitOom@infosec.pub ) English3•6 months ago
Because if you are creating a changelog automatically based on the commit messages it will be very public and that user will look bad.
https://www.conventionalcommits.org/en/about/#tooling-for-conventional-commits
conv commut are used here… Somehow they know how get around thing like git hook
no-verify
:/- CubitOom ( @CubitOom@infosec.pub ) English1•6 months ago
Changelogs are published to stakeholders. So what I’m saying is you don’t have to try to enforce a commit style using got hooks if you have public shaming at your disposal.
- TxzK ( @TxzK@lemmy.zip ) 0•6 months ago
Commit messages of my personal projects are filled with just “fix”. Life is too short to write a proper commit message