Junio C Hamano wrote: > Shawn Pearce <spearce@xxxxxxxxxxx> writes: >> ... But why is this amount of churn necessary or being >> recommended? What problem does this address? Is that worth the pain >> this puts on every other in-flight change that is still being >> developed, or is already in the review pipeline? > > No reason and not recommended; nothing; not worth. > > Especially during the pre-release freeze. It's unlikely the patch would be cooked by the time there is a release, or even in the moments of quiet after that. If this were a patch intended for immediate inclusion, the timing would be unfortunate, but for an RFC I wouldn't have expected the release timing to be very relevant. A better thought out version of this patch, meaning timed appropriately and taking into account the comments that came up the last times the subject was discussed, would imho be a good thing. Part of thinking it through is to consider the effect on in-flight patches and to consider whether it's possible to mitigate that. In other words, I think Shawn's questions get right to the point. I hope the above answers --- which do seem to correctly reflect the state of things in absence of such thinking --- will not dissuade someone from finding a good answer. More prior discussion for the sort of masochistic person who wants to work on it: [1]. I admit I can imagine easier tasks. :) Just my two cents, Jonathan [1] http://thread.gmane.org/gmane.comp.version-control.git/165748/focus=165801 -- 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