Quote from: Hexah on August 27, 2014, 01:48:05 PM

Quote from: fluffypony on August 27, 2014, 01:33:27 PM

-poof-

Nice try. Let's open up a Bytecoin commit from June 25th. Over 1k lines worth of code, and let's open up XMR's commit - 50 lines worth of code. It calls for a question who can and who can not code.

http://www.databasically.com/2011/03/14/git-commit-early-commit-often/ -

"You can clearly see the evolution of this feature, and it makes sense. Not only can you step back (if user permissions were implemented incorrectly, for instance) but Alice was "forced" to think about each logical step of her development process, instead of jumping in head first. It's engineering 101 - break a problem in its atomic elements, and attack each of those."

http://blog.codinghorror.com/check-in-early-check-in-often/ -

"Developers who work for long periods -- and by long I mean more than a day -- without checking anything into source control are setting themselves up for some serious integration headaches down the line."

And to quote from my personal favourite, http://sethrobertson.github.io/GitBestPractices/#commit -

"Git only takes full responsibility for your data when you commit. If you fail to commit and then do something poorly thought out, you can run into trouble. Additionally, having periodic checkpoints means that you can understand how you broke something. People resist this out of some sense that this is ugly, limits git-bisection functionality, is confusing to observers, and might lead to accusations of stupidity. Well, I'm here to tell you that resisting this is ignorant. Commit Early And Often."

Well, I guess you proved that right.