Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > In case it is not crystal-clear, let me clarify one very important point. > It seems that some people mistake the work I do for something I do on a > whim. This is not so. > > The patch series that triggered this entire unfortunate discussion > introduced the --smudge option, which I have subsequently renamed to > --filters and submitted as a patch series to the Git project. As the "--filters" is meant as a new feature, it will not land on the maintenance track. It is very likely that it won't be in 2.10, so it won't appear in 2.10.x maintenance track, either. I do not agree with Duy that the "port to Windows" needs a separate distinct name, though. Having said that, aside from the issue of handling of bugreports has been already meantioned, which mostly costs for Git developers, whatever new feature you unleash ahead of upstream to your Windows port has cost to your end-users. Its implementation or its external interface may have to change when you upstream the new feature that has already been in the field, and your end-users would have to adjust their scripts and/or muscle memory. One way to avoid that risk may be to release the new feature as "experimental-and-subject-to-change", so that interested users on Windows can actually try it out to see if the feature itself (whatever its interface to them is) makes sense, and you can gauge the value of upstreaming it, while cautioning these early adopters that it has not fully been through the usual review process and may have to change while becoming part of the official release. This is no different from various "experimental features" we unleash to the wild, either via 'master' or keeping it in 'next' (we tend to do more of the latter, marking "see if anybody screams"). -- 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