Am Dienstag, 17. Juni 2008 09:02:13 schrieb Per Inge Mathisen: > On Tue, Jun 17, 2008 at 12:35 AM, Dennis Schridde <[EMAIL PROTECTED]> wrote: > >> > 4) Do not mix unrelated cleanup and feature changes or bug fixes in > >> > the same patch. > > ... > > > 4) Seems cumbersome to me, since when I try to fix a bug, some cleanup > > will almost always sneak in, and additionaly I first cleanup and > > understand a function, and then fix it (sometimes it is already fixed by > > the cleanup). I would have to do a lot of surgery... > > Actually, I only added this point as an afterthought because I thought > we all agreed on it in principle. Principle, yes. I am also against commits like "change style in a.c, b.c, ..., z.c and add a tiny feature in k.c". For me the seperation starts to become overkill when it goes like "change style foo(), ..., bar()", "add feature to foo() which affects ..., bar()". I am already trying to seperate it a bit, but if I would be asked to touch every block twice, once for cleanup and once for changes, to get the patch out of the tracker and into the repository, I would ask for payment.
> I am not sure how I can stress enough how important this is. When I go > into the svn log to find a bug, looking through possibly related > changesets is very often a big part of the work. If a commit that > changed some feature that might have caused the bug also contains lots > of 'cleanup' interspersed, this work becomes incredibly much harder. A > less common case is when a change has to be reverted - when cleanup is > part of the same commit, it becomes very much harder to extract, > because it touches so much more code, and usually code that has later > been changed by unrelated commits. It is also much harder to give > comments on patches that contain cleanup, since they take much longer > to read, and you want to read feature changes/bug fixes much more > carefully than cleanup patches. True, but it's a cost/use calculation. How often do you read through change commits which also cleanup the surroundings? And how often do you commit things? Additionaly a change-style-only commit seems rather useless to me. But while I read through functions, I also add spaces here and there so I can get a quick overview faster. The point on reverting is true and I cannot counter it. ;) If you give me a program which automatically seperates style changes from content changes, maybe I would be convinced more easily. ;) --Dennis
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
