Hi, I'm Giuliano and I'm a full stack web developer based in Rome. I love playing around with code trying out new things. I love to share knowledge and get into inspiring conversations.
I never used empty commits, actually didn't even know it was possible.
Still, I'm not totally sure that can help more to document than a well written commit with the relative code; and for triggering automations, most platforms gives the chance to trigger them manually, so no need for an empty commit to do that. Maybe I'm the one who's losing the point here, I'm really open and curious to better understand this empty-commit thing.
Still, thank you for the article, it's indeed really interesting, I learnt something new
What do you mean used in the PR? How are they used in the PR? Do you mean triggering the re-running of PR checks so they somehow pass?
But what would a message for an empty commit say, and does that somehow mark it to not show up in the merge of the PR? Or do you mean this limits you to use the squash option to merge the PR?
My use of empty commit is I have an alias “git note” to add personal notes as commits. I also make the initial commit an empty one for new repos.
this is so wrong.. if you want to trigger the CI just push the button in whatever platform you're using (Azure, gitlab, github, etc)
Empty commits are a bad practice.
I already read thst. it's ok, you have the right to be wrong. If you dont have access to run a CI it's just because you don't have the right level of access to those tools. You could argue that you squash commits before merge but you don't.. Empty commits are just a patch for (in that example) poor permission or access management.
I already read that. Empty commits are wrong. You are using empty commits as a patch to poor permission manager on your projects. Sorry but I will never agree on that.
You git behavior is wrong. You have the right to be wrong but don't spread the word. Also you could argue that you squash commits before merge but you don't because the underneath problem is that you don't know how to use git.
I'll let you fight on a 100.000 people companies dealing with critical secret informations to change their permission policies so you can run a CI by yourself. I'll also let you explain Linus Torvalds why he introduced a wrong feature in its product. Could be an interesting debate 😂
Anyway, no feature are wrong. Some feature are badly used and some feature are useful only in very specific context. If your pipeline is triggered only when a push is done, if you cannot push force the master and if you cannot manually trigger the pipeline, then I don't see any other solution than adding an empty commit on top of the branch.
Hi, I'm Giuliano and I'm a full stack web developer based in Rome. I love playing around with code trying out new things. I love to share knowledge and get into inspiring conversations.
But the not empty commit would yield the same results, as the triggers are push, merge and tag. So the content of the commit would have no bearing on the ability to trigger anything.
I have 23 projects all running automated CI across 3 separate CIs with test, code analysis, deployments of web and backend services, mobile apps and while I’ve known for almost 20 years about an empty commit, the not empty one already does it.
Have you ever made a change to some external setting and wanted to run the pipeline?
I know I have and I've made countless commits where I've simply changed a comment or indentation so I've got something to push. Empty commits would save those pointless changes to the file.
You could definitely re run them from the UI but that means finding the right tab, then the right pipeline, who knows how many clicks. I think I'd be quicker from the console and I can stay in the code context if I've got more work to do.
Yeah, I have shortcuts for basically everything, and I would rather leave the code than add literal junk into my commit history.
Like sure, it would make sense if there was no other way like a public repo where I have no access to the run button, but when I do, I will do it properly, which when I do, is not not push junk into my commit history.
Agreed 1000% with you Ben. The only person who has worked in that environment can understand the importance.
Also, about the UI, on projects with hundreds of maintainers, don't give direct access to CI or third-party buttons/mutual triggers. Bots are used to merge the PRs and empty commit is the only way to re-run those.
Hi, I'm Giuliano and I'm a full stack web developer based in Rome. I love playing around with code trying out new things. I love to share knowledge and get into inspiring conversations.
I agree with Ben too! It actually happens to add a space just to be able to create a new commit and re-run certain processe that are not necessarely easy to get started in different ways.
I still wouldn't abuse empty commits, but they appear to be further more useful of what they seemed at first sight
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I never used empty commits, actually didn't even know it was possible.
Still, I'm not totally sure that can help more to document than a well written commit with the relative code; and for triggering automations, most platforms gives the chance to trigger them manually, so no need for an empty commit to do that. Maybe I'm the one who's losing the point here, I'm really open and curious to better understand this empty-commit thing.
Still, thank you for the article, it's indeed really interesting, I learnt something new
Empty commits are used in the PR. I have seen projects like Kubernetes and Flutter use this for triggering the CI and tests.
What do you mean used in the PR? How are they used in the PR? Do you mean triggering the re-running of PR checks so they somehow pass?
But what would a message for an empty commit say, and does that somehow mark it to not show up in the merge of the PR? Or do you mean this limits you to use the squash option to merge the PR?
My use of empty commit is I have an alias “git note” to add personal notes as commits. I also make the initial commit an empty one for new repos.
this is so wrong.. if you want to trigger the CI just push the button in whatever platform you're using (Azure, gitlab, github, etc)
Empty commits are a bad practice.
I disagree. Read this
dev.to/pradumnasaraf/comment/2810p
I already read thst. it's ok, you have the right to be wrong. If you dont have access to run a CI it's just because you don't have the right level of access to those tools. You could argue that you squash commits before merge but you don't.. Empty commits are just a patch for (in that example) poor permission or access management.
I already read that. Empty commits are wrong. You are using empty commits as a patch to poor permission manager on your projects. Sorry but I will never agree on that.
You git behavior is wrong. You have the right to be wrong but don't spread the word. Also you could argue that you squash commits before merge but you don't because the underneath problem is that you don't know how to use git.
I'll let you fight on a 100.000 people companies dealing with critical secret informations to change their permission policies so you can run a CI by yourself. I'll also let you explain Linus Torvalds why he introduced a wrong feature in its product. Could be an interesting debate 😂
Anyway, no feature are wrong. Some feature are badly used and some feature are useful only in very specific context. If your pipeline is triggered only when a push is done, if you cannot push force the master and if you cannot manually trigger the pipeline, then I don't see any other solution than adding an empty commit on top of the branch.
Oh nice, it makes everything clearer, thank you! This makes actually more sense to me now :D Thank you for the clarification!
But the not empty commit would yield the same results, as the triggers are push, merge and tag. So the content of the commit would have no bearing on the ability to trigger anything.
I have 23 projects all running automated CI across 3 separate CIs with test, code analysis, deployments of web and backend services, mobile apps and while I’ve known for almost 20 years about an empty commit, the not empty one already does it.
Have you ever made a change to some external setting and wanted to run the pipeline?
I know I have and I've made countless commits where I've simply changed a comment or indentation so I've got something to push. Empty commits would save those pointless changes to the file.
You could definitely re run them from the UI but that means finding the right tab, then the right pipeline, who knows how many clicks. I think I'd be quicker from the console and I can stay in the code context if I've got more work to do.
Yeah, I have shortcuts for basically everything, and I would rather leave the code than add literal junk into my commit history.
Like sure, it would make sense if there was no other way like a public repo where I have no access to the run button, but when I do, I will do it properly, which when I do, is not not push junk into my commit history.
Agreed 1000% with you Ben. The only person who has worked in that environment can understand the importance.
Also, about the UI, on projects with hundreds of maintainers, don't give direct access to CI or third-party buttons/mutual triggers. Bots are used to merge the PRs and empty commit is the only way to re-run those.
I agree with Ben too! It actually happens to add a space just to be able to create a new commit and re-run certain processe that are not necessarely easy to get started in different ways.
I still wouldn't abuse empty commits, but they appear to be further more useful of what they seemed at first sight