4 ms·

>Imagine you are working on a software project, there is a massive bug in your code, you know it is there and you intend to work on it before release. If only

>Imagine you are working on a software project, there is a massive bug in your code, you know it is there and you intend to work on it before release. If only we could design a method to openly share the source data, perhaps even with a way to track those bugs. Alas, it's totally impossible for humans to collaborate like that.

GuB-42 6y ago
Yes, I know about GitHub and the like. But working in collaboration is always a hassle, you spend a lot of energy in reporting and getting people to agree. So what you usually do it to do your work locally, maybe have your own TODO list, and when you are done, you clean up your work and make a nice commit. Sometimes you can't even do that, you have to send it to an integrator who then assigns your work to a reviewer and write a test, and... lots of stuff. What you see on GitHub tends to lag significantly behind what is actually being worked on. In fact, a lot of developers tend to dislike messy histories. They take great care of squashing and rebasing so that the history looks like a nice, linear, well documented process. This is not reality, reality is "forgot to add file", "removed debug trace", "fixed merge didn't compile". Now back to the spying. Imagine you are working on an open source project, with a bug tracker, continuous integration, and all the bells and whistles of a modern collaborative platform. Because you don't want to show others the ugly truth of actual development work, if can take a few days before the thing you are working with appears on the platform, if not weeks. Now imagine a rogue actor who doesn't like to collaborate and really wants to get an edge. Instead of getting the nice, clean version from the main repository, he goes to the main developer computer and copies his workspace, and then rush to release something before the next nice commit hits the mainline. That's the idea behind such hacks: try to copy a work in progress, not understanding what went behind it, and, by limiting collaborative effort and testing, try to get something out as fast as possible.

GuB-42 6y ago

Yes, I know about GitHub and the like. But working in collaboration is always a hassle, you spend a lot of energy in reporting and getting people to agree. So what you usually do it to do your work locally, maybe have your own TODO list, and when you are done, you clean up your work and make a nice commit. Sometimes you can't even do that, you have to send it to an integrator who then assigns your work to a reviewer and write a test, and... lots of stuff. What you see on GitHub tends to lag significantly behind what is actually being worked on. In fact, a lot of developers tend to dislike messy histories. They take great care of squashing and rebasing so that the history looks like a nice, linear, well documented process. This is not reality, reality is "forgot to add file", "removed debug trace", "fixed merge didn't compile". Now back to the spying. Imagine you are working on an open source project, with a bug tracker, continuous integration, and all the bells and whistles of a modern collaborative platform. Because you don't want to show others the ugly truth of actual development work, if can take a few days before the thing you are working with appears on the platform, if not weeks. Now imagine a rogue actor who doesn't like to collaborate and really wants to get an edge. Instead of getting the nice, clean version from the main repository, he goes to the main developer computer and copies his workspace, and then rush to release something before the next nice commit hits the mainline. That's the idea behind such hacks: try to copy a work in progress, not understanding what went behind it, and, by limiting collaborative effort and testing, try to get something out as fast as possible.