Live data from Hacker News

Things to commit just before leaving your job

gist.github.com

21–30 of 165 posts

Re: Things to commit just before leaving your job

#21
post #2

We've got a guy in the office that merges the past over the present all the time. He's not quitting but I imagine if you were to try to break things this would be a good way to do it.

I am curious - wouldn't your Version Control system catch this and warn him that "file xyz has changed since you last checked it out, ..." etc?

maybe it does, then he just hammers the "yeah yeah proceed" option to ignore that and make it hurry up and do the thing he wants it to do

Re: Things to commit just before leaving your job

#24
post #6
post #2

We've got a guy in the office that merges the past over the present all the time. He's not quitting but I imagine if you were to try to break things this would be a good way to do it.

Got a offshore guy just like that. Constantly committing his whole project where most files are out of date and only the few he worked on are not. There's no reason for him to commit javascript files he doesn't even work on the front end. It took me forever to figure out he wrote over my files the other day.

Sounds to me like he may not actually understand how git works, or he's following bizarre conventions that I've seen before from overseas devs I've worked with to just overwrite the entire project every commit

Re: Things to commit just before leaving your job

#25
post #11

From the comments my favorite: #define i j

A more unpleasant variant of this would be to combine `#define i j` with a language like Fortran 77 where variables are implicitly typed by letter. e.g. `#define i x` would change the implicit type from int to float...

Re: Things to commit just before leaving your job

#27
post #12

Earlier quoted context omitted.

Of course :) Basically this removes the volatile keyword from your code and replaces it with... nothing. If a variable is declared volatile, it disables compiler optimizations and signals the compiler that this variable can be modified at any time (e.g. by hardware or other threads). Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs ar…

> Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs are extremely hard to reproduce (and thus debug) but lead to deadlocks and/or crashes in case they do occur. In C and C++, volatile is not intended and must not be used for synchronisation primitives, it is not a memory fence (so it does not force cache coherency and does not prevent…

Thanks for clearing that up. I worked with threading a lot in C# hence my misconception that it could be used for spinlocks in C/C++ too.

Re: Things to commit just before leaving your job

#28
post #2

We've got a guy in the office that merges the past over the present all the time. He's not quitting but I imagine if you were to try to break things this would be a good way to do it.

If he still does that after a stern talking to, you should take his commit privileges.

Re: Things to commit just before leaving your job

#29
The horror story that I heard was a disgruntled engineer silently replaced the source codes (C++ based) in the project with compiled binary object files and he kept the source codes on his local computer, not checking those in. He did this over an extended period of time to make sure this crept into the backup tapes as well. No one found out because each engineer owned a code module of their own. Then he resigned.

When his successor tried to debug and enhance the code base, the core files were basically all stripped binary object files...

Post reply on HN