Hi Junio, On Tue, 23 Aug 2016, Junio C Hamano wrote: > 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. Right. Which is even more a reason for me to decouple this feature from non-Windows Git. > [...] 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. This is nothing new. As I said earlier, I have plenty of experience with this. Including the experience of worsimproving a feature that has been battle-tested for years, only to be broken in the process to appease reviewers on the Git mailing list. I talk about the core.hideDotFiles feature, of course, which in the process of being integrated into core Git lost its ability to respect the setting to be "false". Git for Windows has a work-around already, of course, it's just ugly, so I am hesitating to "upstream it" yet. As I said. All of this is old hat. Git for Windows has been, and probably will be for a long time to come, diverging from upstream Git. This is not something I wanted, or worked toward. It's just reality that happened and I have to deal with it and there is nothing to see here, please move on. Ciao, Dscho -- 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