Thanks for the quick responses on this patch! In response to Junio: > "At least you would need two-step process to introduce a change like > this to warn the people whose tools and workflows you are breaking. > That is, (1) in one release, you add code to only detect the case > you will be changing the behaviour in a later version and give > warning messages, and (2) in another release that is several release > cycles later, stop warning and actually change the behaviour.... > I do not mind a two-step breaking of compatibility to address this > issue; I would also understand if the author thinks it is not worth > the hassle to do so. The sudden behaviour change with this patch > alone is however not acceptable, I would think." I understand your hesitance with the original method. If the agreed solution is a two-step implementation, I think it would definitely be worth my time and hassle----in part because I'm particularly excited about the prospect of contributing to Git, but mostly because I do believe that it would be a good improvement. Given this, I'll edit the patch and re-submit to only emit warning messages for now. - Emily -- 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