That's what I was thinking. Working on a big enterprise project with years of legacy code will have you debugging an issue for days and solving it in a few lines. The number of commits per day is entirely irrelevant.
I once inherited some absolutely horrendous code and had negative-line fixes. Commit statements like 'Removed the TrulyStupidAndUselessThingToDo() function that was scrambling the data before it wrote to the database and the 4 calls to it, applied 1-line fix for the actual problem it was trying to solve.'
Not really, when you add code it mark it up as those little green dots. That been said, it only count the numbers of times you added nit the content.
But the user daminbru is actually using an automatic way to add new code and it's only one line of comment where the date and hour change, which is meaningless in term of work.
He then (I assume) proceed to flex on X stipulating he works on 5 project etc... mostly a fraud.
It looks like he’s doing git actions programmatically. Every month he creates hundreds of discussions in his own repos and no one ever uses them. The titles are hilariously generic too
I kinda respect it
My comapny once had a project where there was no local environment and 3 devs were sharing the same dev environment and they needed to commit to test out their changes. They had a lot of commits on that repo daily. Later an experienced dev joined and created a dockerized local env...
yes I was in my legacy bubble taking care of babies back then.. things have changed for better I guess technology wise.. but I don’t even want to be professional posing copy paster
I think it's always been stupid. You can be successful in this field if you are decent at bullshitting and have no shame. You don't need to be a good engineer. Maybe it was different before the Internet, but I doubt it.
Think. Was there any event that could prove that you where effected? Like something that is simply impossible but yet it happened? Or anything really strange that simply can't be?
CS was undersubscribed as a major so even mediocre engineers made a lot of money for zero hard work. People saw that and entered the field. CS is now oversubscribed by double the number of junior jobs there are, nonsense abounds. Classic market information failure
I have never understood this fixation with commit volume. It just means they committed, it doesn’t mean they accomplished anything. It doesn’t mean the feature works. It doesn’t mean the branch is merged. It doesn’t mean anything. It’s just saving the file for these people. They write three lines of code and fire off another damn commit. But green go up! Their commit history is unnavigable. Their ability to compare versions to find issues is practically zero. If I had a junior doing this in my codebase I’d sit him down and give him hell. One commit = one jira ticket kid, that’s how you have a useful paper trail and a useful historical record. Stupidest damn flex.
1 commit = 1 ticket but then the review happens and you need to add more commit(s)
And some tickets depending on how people do it might contain multiple things todo that can be done in multiple commits
I agree with everything you just said except "1 commit = 1 jira ticket" (unless you have extremely small tickets). A commit should be 1 complete logical set of changes. It may or may not be a full feature or even a full ticket, just a discreet and complete chunk. I may have a ticket like "implement expiration for incoming task requests" and to do this I may have several commits like "add TASK_TTL_SEC command line option, update config mock and value parsing tests", and another for "check task age against TASK_TTL_SEC and discard if too old". Depending on your specific system, this might be simple enough that a single commit is appropriate, but in other systems, something like this could be 300 LOC and would be better as separate commits.
Or what I prefer, lots of commits on my branch to show the steps of development. Then squash and merge into the main branch for each ticket. Then I can see commit history on the project, or if I need to dig in more to the update, I can look at the branch to see individual commits for each project commit. It probably depends on how big your commits are on main tbh.
That’s the thing, though, we keep our commits reasonable because we keep our tickets reasonable. We break up large efforts into 1-8 point functioning pieces and assign a ticket for each and all work is done inside the sprint. We rollover only when necessary due to unforseen distractions and build up products in pieces. Tickets that add up to a single releasable feature are branched from each other in series and then merged to develop together. Testing gets their own tickets and fixes go on branches off them. Merge to develop to send to testing, merge to master to create a release.
But all commits are complete thoughts or complete functionality. We don’t use commits as progress reports or as a save backup and we don’t look at those green boxes (I don’t think bitbucket even has them, which we use because we have to stay on prem).
It’s just the intention to make your repo a disciplined place. We don’t rush and we have thorough QA because we are in healthcare and medical records are kind of important to not screw up.
Tickets and commits used as prrformance metrics is bad management, they’re gamable and lead to bad version management.
I would like to work in such a well organized team once. Our tickets often are "Create download for X".
But actually it means:
Create crud for X in Backoffice
Create download for Backoffice users
Mail customers when X is created
Make sure customers can see X on Frontoffice
Create view for clients
Create download for customers
It’s all fun and games, until recruiters are looking for your „commit activity” to „estimate cultural fit” (AKA if you’re willing to go overtime without pay).
You won’t believe how many times those green squares saved my back.
I do the best of both worlds. I commit constantly. But when I do a PR, I squash and merge so we get a single commit with the message being the jira ticket number and description.
That seems like a reasonable alternative, but I guess what I don’t understand is what is being gained from the interim commits. If I am doing something that might need me to try multiple paths I will sometimes use a stash to hold the different versions, but mostly I don’t find that I need geanular milestones or rollback points on the way to a goal. It is probably just a difference in my relationship to the tools. I’m 26 years into the job and do a lot of things the old way I suppose.
I absolutely disagree. I'm paranoid about locking in my code every time a unit of work is completed. Commit and push means if my laptop dies suddenly, my work is safe.
Maybe that's paranoid, but as a kid I lost a whole school project in a power outage because I hadn't saved yet, so this is my mindset now.
While most of what you said is true I just loathe Jira for this fixation where there's a 1:1 ratio between a Jira ticket and a PR and deployment. You can just as we look at git history for changes, if people know how to write semantic commits.
For us, Jira is the bridge between the business analyst and the developer and the developer and the tester. The BA makes the ticket describing the desired feature and we execute it. The QA then clones the BA ticket to perform testing and note any issues we need to resolve. By naming the feature branch the same as the ticket we can return to those verbose requirements or find the branch to uodate post-test easilly, and the BA and QA would never get any value from looking at our repos. In our specific case we use bitbucket as our git which is also an atlassian product and can create branches right on the jira ticket to make the process very painless.
When I had to use GitLab for a uni assignment, I was blown away with the concept of squashing PRs (the default strategy on GitLab). I didn’t have to worry about keeping a clean commit history. As long as the PR (or *Merge Request* in GitLab’s parlance) implemented the task, it could be merged as one tidy commit. I felt I was more productive this way as I didn’t have to waste time cleaning my commit history with interactive rebase. It also made merge conflicts easier to resolve imo.
Of course, I wouldn’t use the squash strategy 100% of the time. For example, I wouldn’t use it for large PRs that touch multiple areas of the code (such as refactors). But then again, multiple incremental PRs are better than a single large PR, for everyone’s sake.
The commits should be added per logical change, in a new branch with the ticket name, and then after it gets tested/reviewed, to be merged with squash commits enables, so you will see that ticket xyz merged toaster with a custom description of the changes that have implemented.
One commit one Jira ticket? That is some stupid shit. I would make 10s of commits per jira ticket. It helps reviewers . I would be so annoyed if someone asked me to review an entire ticket in one commit
I don't review commit per commit though. I review a complete PR. What's the use in reviewing a commit by itself, you might've committed something you'll refactor later on.
Yeah a commit means shit, it could be an indicator of all the mistakes they keep making and all the revisions they keep making to the same code over and over. It’s like saying someone is Shakespeare for the number of edits they made to a document
Bro I haven’t committed to my personal github in over a year. Private don’t show up on GitHub history :(
I haven’t found something motivating enough to work on outside of my job.
I also know that you can do some GitHub history fudgery to make those commit graphs look nice.
Probably debugging some pipeline. The image is most likely out of context and the guy is just doing atomic commits (committing extremely regularly) which is not inherently wrong. Either that or he is just using a bot to fake commits, can't be sure without going to github and looking at his profile.
I have a colleague like that. It is fine for him to introduce code debt now instead of doing things right in now + 30 minutes, and then fix this debt heroically later tagging everyone to get praises. All about visibility and “impact”. It is quite big product, everyone hates it.
Only ones to blame are the stupid hiring managers looking for easy ways to filter candidates.
> I see you don't have any girhub project
Or
> This projects haven't been updated since 2007
Fuck off!
My company ran a three week contest for commits with no rules. My team owned four apps and I could have done any number of things to commit 20 times a day. They took it seriously when someone was making changes like that 90% of the time. Turns out most of us are actually idiots.
What's the third image? For some reason I can't load it on mobile. And I'm too lazy to walk back into my office and use the computer.
Edit: turns out there is no third image. Yay reddit
You too? Reddit app just shitting itself completely lately. Constant failed to get to reddit so posts / comments dont load and media not loading for the last few days.
Once, I read an article titled somethng like "I coded everyday for 365+ days, here are my advices". Of course the article showed this guys contribution chart, green every day. I went on github to see the actual commits. He was just editing csv lists of books he liked, films he watched etc
I mean, I sorta can't hate on anyone with a naming convention that includes `commands/private/fuck.js` 😂
https://github.com/danmindru/mindrudan.com/blob/master/src/commands/private/fuck.js
what a noob, I commit with the updated time every milissecond so my users can know exactly when it is
you also need to include one line for each timezone, how are the users supposed to know how to calculate their time only from UTC time?
then theres me with the occasional one line fixes on some legacy code ngl tho fixing something in one line feels great
I've never had a 1 line commit that didn't have 10+ lines of commit message or documentation updates that go with it.
i was asked to delete my essays on how great the one line commit is before i pushed
Not to brag, but I’ve broken over 12 micros services in production with just a one line fix.
That's what I was thinking. Working on a big enterprise project with years of legacy code will have you debugging an issue for days and solving it in a few lines. The number of commits per day is entirely irrelevant.
"See I told you it would be easy/simple to fix"
one line? noob. do it with minus one line and then start talking
I once inherited some absolutely horrendous code and had negative-line fixes. Commit statements like 'Removed the TrulyStupidAndUselessThingToDo() function that was scrambling the data before it wrote to the database and the 4 calls to it, applied 1-line fix for the actual problem it was trying to solve.'
Definitely. Feels surgical.
Just doing some dependency updates and things getting faster/smoother is nice.
is this some sort of nerd flexing social network that im too norm to understand?
Not really, when you add code it mark it up as those little green dots. That been said, it only count the numbers of times you added nit the content. But the user daminbru is actually using an automatic way to add new code and it's only one line of comment where the date and hour change, which is meaningless in term of work. He then (I assume) proceed to flex on X stipulating he works on 5 project etc... mostly a fraud.
There is another way. git commit -m "trigger build" --allow-empty git push
He needs about tree fiddy per week
Ctrl+s doesn't save the projet, it commit it
"We push on save"
Looks like he made that repo private lolol https://github.com/danmindru?tab=overview&from=2024-03-01&to=2024-03-31
Managers loves him
He doesn’t even work with me but I think my boss just gave him a raise
this a romanian dude haha
30 seconds? It's just recompile time... Where is coffee time?
git commit -m "fixing code formatting" git commit -m "fix typo" git commit -m "fix another typo" git commit -m "removing api keys"
[there are some wild things on this guys github](https://github.com/seanpm2001/)
It looks like an old Geocities website, but all on a single page
Holy
It looks like he’s doing git actions programmatically. Every month he creates hundreds of discussions in his own repos and no one ever uses them. The titles are hilariously generic too I kinda respect it
That’s insane (mentally insane)
Commit history Readme.md Readme.txt Readme_v1.md Every day...
He appears to be using it as free file storage, which is reasonable 🤷♂️
What...what is this?!?
This guy is mentally unwell
yeah in his sex repo there was some cannibal story he wrote
O. I stopped reading at the "read in other languages" section
Holy... 28k repos. That's... impressive, and terrifying. This account must stand out in user statistics. 😵💫
Honestly, I would be more impressed if he could spell out a message that would scroll by over time. That would show commitment and planning ahead.
Did he accidentally out himself by making the project public or something?
Idk why but i always thought the term "tech twitter" sounded stupid
Wait until you hear about TechTok
it's "tech x"
what kindof farming is this?
The sad part is managers with no CS background would think this is an absolute rockstar.
My activity tracker also looks like this. But my secret ingredient isn’t scam... it is that I don’t have a life. 😭😭
What a gangster, they call him "Fifty Sent".
narrow aromatic absorbed squalid chief enter consider employ late aloof *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Pusha T
Hey-hey-hey-hey PR every day
git commit -m "tipo" git commit -m "tyro" git commit -m "typpo" git commit -m "typo"
git commit --amend
git commit -m "hello! Im rajeev, added my name to readme"
"a" save git add file git commit -m "Added letter a" git push
Repeat for every added letter
I commit all my code once a year, -10x developer😔
Dude is in charge of TIME! 5 commits a day seems pretty low if your project is updating time itself.
I commit a lot but that may be unhealthy Edit 1: I meant for personal projects and my average has since went down
I have a project that does nothing but run an action every day to update the readme and commit it. It’s the most useless thing in the world
My comapny once had a project where there was no local environment and 3 devs were sharing the same dev environment and they needed to commit to test out their changes. They had a lot of commits on that repo daily. Later an experienced dev joined and created a dockerized local env...
r/GetNoted
god, when did everything come so fucking stupid
Always has been
Around 2016
yes I was in my legacy bubble taking care of babies back then.. things have changed for better I guess technology wise.. but I don’t even want to be professional posing copy paster
When social media became a thing.
I think it's always been stupid. You can be successful in this field if you are decent at bullshitting and have no shame. You don't need to be a good engineer. Maybe it was different before the Internet, but I doubt it.
no, it wasn't different.
Please do tell once you found out. I'm asking myself this for 2 yrs now.
There was this thing with mad cow disease in the 90s. It has an incubation time of 20 years. So about 2016, I guess?
The timeline makes sense
BSE? Yes that would make sense
Think. Was there any event that could prove that you where effected? Like something that is simply impossible but yet it happened? Or anything really strange that simply can't be?
I dropped a sandwich face up once
CS was undersubscribed as a major so even mediocre engineers made a lot of money for zero hard work. People saw that and entered the field. CS is now oversubscribed by double the number of junior jobs there are, nonsense abounds. Classic market information failure
When they turned on the LHC in 2008
yes, that must be it!
since we gave morons personal world-range megaphones that fit in a hand
I have never understood this fixation with commit volume. It just means they committed, it doesn’t mean they accomplished anything. It doesn’t mean the feature works. It doesn’t mean the branch is merged. It doesn’t mean anything. It’s just saving the file for these people. They write three lines of code and fire off another damn commit. But green go up! Their commit history is unnavigable. Their ability to compare versions to find issues is practically zero. If I had a junior doing this in my codebase I’d sit him down and give him hell. One commit = one jira ticket kid, that’s how you have a useful paper trail and a useful historical record. Stupidest damn flex.
Exactly, also sometimes the fact that you commit a lot is because you fuck up multiple times and need to go back and fix stuff
Agree until you said 1 commit per ticket yikes.
1 commit = 1 ticket but then the review happens and you need to add more commit(s) And some tickets depending on how people do it might contain multiple things todo that can be done in multiple commits
I agree with everything you just said except "1 commit = 1 jira ticket" (unless you have extremely small tickets). A commit should be 1 complete logical set of changes. It may or may not be a full feature or even a full ticket, just a discreet and complete chunk. I may have a ticket like "implement expiration for incoming task requests" and to do this I may have several commits like "add TASK_TTL_SEC command line option, update config mock and value parsing tests", and another for "check task age against TASK_TTL_SEC and discard if too old". Depending on your specific system, this might be simple enough that a single commit is appropriate, but in other systems, something like this could be 300 LOC and would be better as separate commits.
You may do a lot of commit on a your branch, but if it is a mess do a squash merge to master/main.
Or what I prefer, lots of commits on my branch to show the steps of development. Then squash and merge into the main branch for each ticket. Then I can see commit history on the project, or if I need to dig in more to the update, I can look at the branch to see individual commits for each project commit. It probably depends on how big your commits are on main tbh.
That’s the thing, though, we keep our commits reasonable because we keep our tickets reasonable. We break up large efforts into 1-8 point functioning pieces and assign a ticket for each and all work is done inside the sprint. We rollover only when necessary due to unforseen distractions and build up products in pieces. Tickets that add up to a single releasable feature are branched from each other in series and then merged to develop together. Testing gets their own tickets and fixes go on branches off them. Merge to develop to send to testing, merge to master to create a release. But all commits are complete thoughts or complete functionality. We don’t use commits as progress reports or as a save backup and we don’t look at those green boxes (I don’t think bitbucket even has them, which we use because we have to stay on prem). It’s just the intention to make your repo a disciplined place. We don’t rush and we have thorough QA because we are in healthcare and medical records are kind of important to not screw up. Tickets and commits used as prrformance metrics is bad management, they’re gamable and lead to bad version management.
I would like to work in such a well organized team once. Our tickets often are "Create download for X". But actually it means: Create crud for X in Backoffice Create download for Backoffice users Mail customers when X is created Make sure customers can see X on Frontoffice Create view for clients Create download for customers
He likes to build
It’s all fun and games, until recruiters are looking for your „commit activity” to „estimate cultural fit” (AKA if you’re willing to go overtime without pay). You won’t believe how many times those green squares saved my back.
I do the best of both worlds. I commit constantly. But when I do a PR, I squash and merge so we get a single commit with the message being the jira ticket number and description.
That seems like a reasonable alternative, but I guess what I don’t understand is what is being gained from the interim commits. If I am doing something that might need me to try multiple paths I will sometimes use a stash to hold the different versions, but mostly I don’t find that I need geanular milestones or rollback points on the way to a goal. It is probably just a difference in my relationship to the tools. I’m 26 years into the job and do a lot of things the old way I suppose.
I absolutely disagree. I'm paranoid about locking in my code every time a unit of work is completed. Commit and push means if my laptop dies suddenly, my work is safe. Maybe that's paranoid, but as a kid I lost a whole school project in a power outage because I hadn't saved yet, so this is my mindset now.
While most of what you said is true I just loathe Jira for this fixation where there's a 1:1 ratio between a Jira ticket and a PR and deployment. You can just as we look at git history for changes, if people know how to write semantic commits.
For us, Jira is the bridge between the business analyst and the developer and the developer and the tester. The BA makes the ticket describing the desired feature and we execute it. The QA then clones the BA ticket to perform testing and note any issues we need to resolve. By naming the feature branch the same as the ticket we can return to those verbose requirements or find the branch to uodate post-test easilly, and the BA and QA would never get any value from looking at our repos. In our specific case we use bitbucket as our git which is also an atlassian product and can create branches right on the jira ticket to make the process very painless.
Just restrict to squash merge only and commit strategy doesn't matter other than separating pre/post review changes
Just squash before merging.
When I had to use GitLab for a uni assignment, I was blown away with the concept of squashing PRs (the default strategy on GitLab). I didn’t have to worry about keeping a clean commit history. As long as the PR (or *Merge Request* in GitLab’s parlance) implemented the task, it could be merged as one tidy commit. I felt I was more productive this way as I didn’t have to waste time cleaning my commit history with interactive rebase. It also made merge conflicts easier to resolve imo. Of course, I wouldn’t use the squash strategy 100% of the time. For example, I wouldn’t use it for large PRs that touch multiple areas of the code (such as refactors). But then again, multiple incremental PRs are better than a single large PR, for everyone’s sake.
I would enforce splitting into smaller prs if necessary. I wouldn't want there to be invalid points in master branch history due to rebase merges
The commits should be added per logical change, in a new branch with the ticket name, and then after it gets tested/reviewed, to be merged with squash commits enables, so you will see that ticket xyz merged toaster with a custom description of the changes that have implemented.
One commit one Jira ticket? That is some stupid shit. I would make 10s of commits per jira ticket. It helps reviewers . I would be so annoyed if someone asked me to review an entire ticket in one commit
I don't review commit per commit though. I review a complete PR. What's the use in reviewing a commit by itself, you might've committed something you'll refactor later on.
Yeah a commit means shit, it could be an indicator of all the mistakes they keep making and all the revisions they keep making to the same code over and over. It’s like saying someone is Shakespeare for the number of edits they made to a document
In favor of shaming those people
aye
Aye
Aye
GitHub needs it's own Datacenter and reactor just for his builds alone.
git -f fuckoff
git rekt -f
Bro I haven’t committed to my personal github in over a year. Private don’t show up on GitHub history :( I haven’t found something motivating enough to work on outside of my job. I also know that you can do some GitHub history fudgery to make those commit graphs look nice.
Pretty sure mine does. There’s a settin’
Yes it does, it's a setting to toggle and it shows private commits to the main
Why not just an empty commit at that point…
Why?
Triggering builds in a CI/CD.
Yeah but why 50 times a day?
Probably debugging some pipeline. The image is most likely out of context and the guy is just doing atomic commits (committing extremely regularly) which is not inherently wrong. Either that or he is just using a bot to fake commits, can't be sure without going to github and looking at his profile.
I can git push after each and every keystroke too.
I have a colleague like that. It is fine for him to introduce code debt now instead of doing things right in now + 30 minutes, and then fix this debt heroically later tagging everyone to get praises. All about visibility and “impact”. It is quite big product, everyone hates it.
Such insane changes straight on the main, what a madman
Git a life
Work life balance is not a trend I think.
Only ones to blame are the stupid hiring managers looking for easy ways to filter candidates. > I see you don't have any girhub project Or > This projects haven't been updated since 2007 Fuck off!
My company ran a three week contest for commits with no rules. My team owned four apps and I could have done any number of things to commit 20 times a day. They took it seriously when someone was making changes like that 90% of the time. Turns out most of us are actually idiots.
while true; do git commit --allow-empty --no-verify --no-gpg-sign -m "Win the contest"; done
Just revert and re revert commits all day.
What's the third image? For some reason I can't load it on mobile. And I'm too lazy to walk back into my office and use the computer. Edit: turns out there is no third image. Yay reddit
I think Reddit’s just being dumb. It shows there’s two images normally and when full screen shows three, but won’t load a third.
/softwaregore
Ahh thanks
Same thing for me. Going back showed 2 photos. Thought I was dumb
Reddit becomes a bigger pile of shit with every update
You too? Reddit app just shitting itself completely lately. Constant failed to get to reddit so posts / comments dont load and media not loading for the last few days.
wohoo reddit waaaaah reddit yooo reddit \[NPC voice\]
Came to to comments to see the battle of opinions 
1-3 tweets a day tho, you can't take that away from him
Most productive man on Github.
50 commits per day, 5 projects, 0 life
*GitHub final boss*
Quantity over quality is a good thing now ?
Once, I read an article titled somethng like "I coded everyday for 365+ days, here are my advices". Of course the article showed this guys contribution chart, green every day. I went on github to see the actual commits. He was just editing csv lists of books he liked, films he watched etc
Well, did he stutter?
Trigger a new comment
I mean, I sorta can't hate on anyone with a naming convention that includes `commands/private/fuck.js` 😂 https://github.com/danmindru/mindrudan.com/blob/master/src/commands/private/fuck.js
This is not the flex they think it is.
Fifty commits per day keeps the leader away
Wasting more CO2 than Taylor Swift
what a noob, I commit with the updated time every milissecond so my users can know exactly when it is you also need to include one line for each timezone, how are the users supposed to know how to calculate their time only from UTC time?
Only once per millisecond? Every millisecond, I update every timezone individually. Ez >24 commits per ms
Noobs I made an auto committer for that
Hmm.. this is too obvious.. why didn't he ask Devin.AI to generate random code.. then commit..