Let me elaborate to you, how and why I wanted to implement the makeheaders tool in the project. First of all, this program will automatically generate c header(.h) files for specified c source(.c) files, which will help the developer. Here the test shows how the tool can be implemented in different cases: https://github.com/skrab-sah/makeheaders-test pros: 1. it will slightly reduce the size of the project. 2. no need to declare anything in the header file, which is time consuming and a headache for developers. On Mon, 19 Sept 2022 at 23:10, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > > > On Mon, Sep 19 2022, Skrab Sah wrote: > > > > Just sending a $subject is rather light on details, so I'm having to do > > a lot of guessing, but here goes. > > ... > > In case this is a genuine "prep question" that you're asking in > > wonderining if you should even waste time on coming up with a patch to > > do $subject I want to say that: > > ... > > Now, this does *not* mean that we're not interested, but just that we're > > very big on a "show your work" approach to things. > > Perhaps this should be made into a FAQ entry? > > In general, we do not give promises or guidance, but something a > contributor finds it rewarding to work on, whether we would leter > accept in the upstream, will spread among users and developers, and > eventually we would come begging to the contributor for upstreaming. > > On the other hand, a new thing that the contributor who thought of > does not feel it is worth investing their work in, if only to use > for themselves, is unlikely to be of interest to us. > > So saying "if this will be accepted, I'll work on it" is counter > productive, as it is easily (mis)taken as a sign that it is the > latter case. > > In other words, make it so good that we would come to you. > > Thanks. >
