Diff couldn't care less. I care. I have to read less for that.chuck_starchaser wrote:That's ideal for a diff; NOT ideal for Humans, and workflow.
But if you don't want my help just go on committing like that. I can't find a change among a thousand unrelated lines, trac or no trac.
Minor cosmetic changes. Using that argument to justify using uncrustify on a file is like saying "fuck you". At the very least, uncrusfity, commit the uncrustification, and then go on working.chuck_starchaser wrote:You're taking the exact same position HellcatV took, namely that there should only be changes in sources that cause
the executable to change; or perhaps that cosmetic changes should be completely separate. Well, that's just not
realistic. When I'm working with code I notice things that could make the code more readable, a variable name that
would be better, a const that was missed, etceteras.
Visual tools can't separate the relevant changes from the irrelevant.chuck_starchaser wrote:I just showed you that trac makes it clearer. Well, Meld makes it even clearer. We've got visual tools; let's
use them. We shouldn't restrict our actions to complete paralysis, just so that old style diffs look clean. What needs
to look clean is the code; NOT the diffs.
And to answer like that is to say "fuck you".chuck_starchaser wrote:Yes, and I will continue to do so.But interspersed in that commit is reformatting stuff to beam_generic.cpp, for instance.
Sorry.
There's just no better time to refactor a class than when you're working with it --for no matter how unrelated a reason.
And to expect any less is to adopt HellcatV's stance and forestall continuous improvement.
That's arguable. With that same argument I could have named it piImage (pointer to image). Then apuiImage (auto-ptr to Unit Image). Then everything gets out of control. Hungarian notation is widely hated for getting out of control rather easily.chuck_starchaser wrote:It's like my changing the "image" member of Unit to "pImage". That was not necessary to refactoring; it's
just a more appropriate name for a pointer. And inside *pImage there's two pointers I changed into auto_ptr<>'s, and later back to
pointers;
Ehm... merging doesn't produce diffs, but anyway, check out one of the graphical diff viewing tools out there (kdiff, for instance).chuck_starchaser wrote:but now I got this diff I don't understand, opened in vim, a program I don't know well at
all. And I've slept maybe 4 hours in the past 3 days, and eaten twice; so I'm going nuts.
I give up.chuck_starchaser wrote:That's not realistic. I don't have that much control of my sphincter, let alone my creative juices. Let the tools serve us; not us serve the tools.And you'll help others by keeping the changes committed in a single commit all related.
I told you why. 15000 lines changed, 50 are const changes, 50 are macros, the rest reformatting. I won't spend my day finding the 50 lines I care about in an ocean of 15000, as much as you won't spend the effort to commit them separately.chuck_starchaser wrote:I'm a big fan of team work and peer review; I'm just not getting any.
Good tip.chuck_starchaser wrote:I don't think it has anything to do with OpenGL; tell you why: because the game loads faster than ever; so it's just not doing anything related to loading those images, IMO.
Yeah... it didn't make the game not load images or anything like thatchuck_starchaser wrote:Well, you predicted a week ago or two that using a code formatter was going to be hell on earth, and uncrustify proved you wrong. Naturally you don't trust it. Thing is, I uncrustified the entire goddam sources and they was still building and running. What more proof do you need?
You must have a smarter compiler than mine.chuck_starchaser wrote:Ditto. The chances that uncrustify CAUSED a bug are pretty much nil. They'd have to be pretty sophisticated "bugs" for them to get past the compiler and only affect run-time behavior.
Don't worry. Won't happen again.chuck_starchaser wrote:What I found most insulting was actually your asking me for list of changes, as if I had been so inefficient with my time that such lists would be short and sweet. I made gazillions of changes.