Mark Lodato <lodatom@xxxxxxxxx> writes: > On Fri, Jun 12, 2009 at 8:14 PM, Junio C Hamano<gitster@xxxxxxxxx> wrote: >> Mark Lodato <lodatom@xxxxxxxxx> writes: >> >>> If this patch series is accepted, I >>> will make a cleaner version that includes this change. >> >> Sorry, but I do not understand this part of your message. > > Sorry about that. I meant that I have cleaned up the code as you > suggested (see diff below), and that if you decide to include the > patch series into git.git (I see now you included it in pu), I can > either submit an additional patch to perform the cleanup, or submit a > new "v2" patch series incorporating these changes. Is one preferred > over the other? Ah, I see. Here is how we do things around here. Reviewers are usually faster to comment and offer improvement suggestions than I pick up patches and apply them to my tree (in any branches). While a patch is under active discussion with suggestions that make the code obviously better with simple changes, the submitter is expected to send new "v$n" (n>=1) patches incorporating suggested improvements. It often is simpler and cleaner if such "replacement" patches are sent for anything that hasn't landed on 'next' (or 'master/maint' for that matter), and I make sure not to merge something that still has iffiness to 'next' (iow, keeping it on 'pu') to help this process. After the initial dust settles and reviewers agree that the patch is in a good testable state, it lands in 'next', and if there are further improvements and bugfixes, they are expected to be sent as incremental patches. That way, we do not have to record obvious shortcomings that tend to appear in the initial submission in our history, while keeping the record of incremental updates on top of what has been judged as "basically sound" (aka "advances to 'next'"). So in this case, v2 is very much preferred. There is no point recording "Mark originally sent a code with #ifdef sprinkled heavily and then later realized that the code becomes easier to read if #ifdef part is separated out to only define the constants used in the code" as part of our official history. By the way, I forgot to say this even though I noticed you are new: welcome to git development community. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html