On 2023-09-02 20:47, Junio C Hamano wrote:
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.
Oh, totally! A good idea with a poor implementation is something that
simply can't be accepted and merged. No promises can be made until the
code is available for review.
- 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.
I agree, the mantra of open-source could be formulated as something like
"find an itch and scratch it" or "build it and they will come". In
other words, if someone finds something useful and worth investing their
time, perhaps other people will find it useful, too.
"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
;-).
Thank you very much for your thoughts and the time required to write it
all down. I'll do my best to make my patch(es) irresistible. :)
