4 ms·

Could be good for resume padding. O yea, I wrote 75% of linux...

cratermoon 5y ago
This thought occurred to me, too. The example given is about pinning bad code on someone else, but the inverse is also possible: changing the author of good code to yourself. I'm kind of wondering, now, if there are some unscrupulous coders out there messing with their employer's internal git repos to give themselves credit for work other people did. I knew one guy who would create tickets, assign them to himself, and then abuse the tickets closed metric to inflate his productivity claims. He wasn't very subtle about it, either. Of course management ought to have been more skeptical of that, but .. stuff happens. Yeah, I work in information security for a living, how did you guess?
- mb7733 5y ago
  Well for one thing, the unscrupulous employee would need to have force push permissions to the origin repo. Even if they they did, once they change the history change, other developers working with the repo would be alerted of the remote branch changing out from under them next time they try to pull. And even if the change doesn't result in a conflict, and each of those other devs blindly accept the resulting merge, the original authors' commits will still be in the history resulting from the merge. So if those developers ever pushed anything, the original commits would be re-introduced. Now, it could be abused if a single developer inherits a project that nobody else has checked out. But it's still a high risk strategy for the unscrupulous dev.
  - cratermoon 5y ago
    > Well for one thing, the unscrupulous employee would need to have force push permissions to the origin repo. Have you ever seen that old video "The website is down"? [1]. In it, the guy covers his own tracks with admin privileges. I'm not saying it's easy, just that it's possible.
dylan604 5y ago
I've worked with that dev. After 2 weeks on the job, you realize the resume was full of shit, and are actively looking at ways to replace that dev.

This thought occurred to me, too. The example given is about pinning bad code on someone else, but the inverse is also possible: changing the author of good code to yourself. I'm kind of wondering, now, if there are some unscrupulous coders out there messing with their employer's internal git repos to give themselves credit for work other people did. I knew one guy who would create tickets, assign them to himself, and then abuse the tickets closed metric to inflate his productivity claims. He wasn't very subtle about it, either. Of course management ought to have been more skeptical of that, but .. stuff happens. Yeah, I work in information security for a living, how did you guess?

mb7733 5y ago
Well for one thing, the unscrupulous employee would need to have force push permissions to the origin repo. Even if they they did, once they change the history change, other developers working with the repo would be alerted of the remote branch changing out from under them next time they try to pull. And even if the change doesn't result in a conflict, and each of those other devs blindly accept the resulting merge, the original authors' commits will still be in the history resulting from the merge. So if those developers ever pushed anything, the original commits would be re-introduced. Now, it could be abused if a single developer inherits a project that nobody else has checked out. But it's still a high risk strategy for the unscrupulous dev.
- cratermoon 5y ago
  > Well for one thing, the unscrupulous employee would need to have force push permissions to the origin repo. Have you ever seen that old video "The website is down"? [1]. In it, the guy covers his own tracks with admin privileges. I'm not saying it's easy, just that it's possible.

dylan604 5y ago

I've worked with that dev. After 2 weeks on the job, you realize the resume was full of shit, and are actively looking at ways to replace that dev.