Dragan Simic <dsimic@xxxxxxxxxxx> writes: > I'd like to implement support for a new configuration option named > "diff.statNameWidth" and submit the patch, so I'd like to check first > would that patch be accepted and merged. In general, we do not give promises or estimates. The devil is in the details and until we see the design we may not know if an overall idea is good. Even when it is obviously a good idea, we would not know the quality of the implementation until we see it. - If something is worth adding, even if we do not accept it in the upstream first, it will spread among users and developers, and eventually we may realize the mistake of initially not taking it and we may come begging to the contributor for upstreaming. - On the other hand, a new thing that even the contributor themselves are unsure if it is worth investing their work in, if it is only to use it for themselves, is very unlikely to be of interest to us or our users. "If this will be accepted, I'll work on it" is a very counter productive thing to say around here. It is easily (mis)taken as a sign that it is the latter case. "This is a good idea, I believe in it, and I'll work on it whether you initially show interest or not" is what we want to see, and such a patch will not need a "check first" letter. In other words, make it so good that we would come to you, begging ;-). Thanks.