[RFC] New configuration option "diff.statNameWidth"

[RFC] New configuration option "diff.statNameWidth"

[Dragan Simic]

Hello,

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.

Similarly to the already existing configuration option 
"diff.statGraphWidth",[1][2] "diff.statNameWidth" as a new configuration 
option would limit the width of the filename part in generated diffstat 
outputs, just like the command-line option "--stat-name-width=<n>" 
already does.

Having "diff.statNameWidth" as a new configuration option would be quite 
usable, and it would fit together nicely with the already existing 
"diff.statGraphWidth" configuration option.  For exaple, I have quite a 
few aliases in my ~/.gitconfig that contain "--stat-name-width=<n>", and 
having this new configuration option would allow those aliases to be 
much shorter.  Of course, it would benefit all other uses in which 
diffstats are generated.

Please advise.

Links:
[1] 
https://git-scm.com/docs/git-diff#Documentation/git-diff.txt---statltwidthgtltname-widthgtltcountgt
[2] 
https://git-scm.com/docs/git-config#Documentation/git-config.txt-diffstatGraphWidth

Re: [RFC] New configuration option "diff.statNameWidth"

[Junio C Hamano]

Dragan Simic <dsimic@manjaro.org> 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.

Re: [RFC] New configuration option "diff.statNameWidth"

[Dragan Simic]

On 2023-09-02 20:47, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> 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. :)

Re: [RFC] New configuration option "diff.statNameWidth"

[Junio C Hamano]

Dragan Simic <dsimic@manjaro.org> writes:

> 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. :)

Heh, I have to send the same from time to time, so it didn't take
that much time.  Having said all the above, once we start seeing the
actual patches and its sales pitch (aka proposed commit log
message), we do guide and help polishing the patch into a better
shape, so it will not be like the contributor has to work in the
dark without knowing what level of bar their contribution has to
pass.

Thanks.

Re: [RFC] New configuration option "diff.statNameWidth"

[Dragan Simic]

On 2023-09-03 00:16, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
> 
>> 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. :)
> 
> Heh, I have to send the same from time to time, so it didn't take
> that much time.

Quite frankly, I suspected that to be a canned response, :) but anyway, 
preparing that response, and possibly refining it over a couple of 
iterations, surely already took a fair amount of time and effort.

> Having said all the above, once we start seeing the actual patches
> and its sales pitch (aka proposed commit log message), we do guide
> and help polishing the patch into a better shape, so it will not
> be like the contributor has to work in the dark without knowing
> what level of bar their contribution has to pass.

Thanks, everything sounds great and welcoming to the new contributors, 
who of course need to be willing to put in the required amount of skill 
and effort.

Re: [RFC] New configuration option "diff.statNameWidth"

[Dragan Simic]

On 2023-09-03 05:43, Dragan Simic wrote:
> On 2023-09-03 00:16, Junio C Hamano wrote:
>> Having said all the above, once we start seeing the actual patches
>> and its sales pitch (aka proposed commit log message), we do guide
>> and help polishing the patch into a better shape, so it will not
>> be like the contributor has to work in the dark without knowing
>> what level of bar their contribution has to pass.
> 
> Thanks, everything sounds great and welcoming to the new contributors,
> who of course need to be willing to put in the required amount of
> skill and effort.

I sent a patch to the git mailing list today, about five hours ago, but 
it hasn't appeared on the list yet.  Could something be wrong with the 
mail server(s), as I also received no other messages from the list in 
the last six hours or so?

Re: [RFC] New configuration option "diff.statNameWidth"

[Junio C Hamano]

Dragan Simic <dsimic@manjaro.org> writes:

> On 2023-09-03 05:43, Dragan Simic wrote:
>> On 2023-09-03 00:16, Junio C Hamano wrote:
>>> Having said all the above, once we start seeing the actual patches
>>> and its sales pitch (aka proposed commit log message), we do guide
>>> and help polishing the patch into a better shape, so it will not
>>> be like the contributor has to work in the dark without knowing
>>> what level of bar their contribution has to pass.
>> Thanks, everything sounds great and welcoming to the new
>> contributors,
>> who of course need to be willing to put in the required amount of
>> skill and effort.
>
> I sent a patch to the git mailing list today, about five hours ago,
> but it hasn't appeared on the list yet.  Could something be wrong with
> the mail server(s), as I also received no other messages from the list
> in the last six hours or so?

It is a high-volume mailing list server and occasional hiccup is
part of regular life.  Waiting a bit and then poking the postmater
at vger.kernel.org may be needed from time to time, but I am seeing
your message on the archive, so it seems "waiting" has worked fine?

Re: [RFC] New configuration option "diff.statNameWidth"

[Dragan Simic]

On 2023-09-12 01:02, Junio C Hamano wrote:
> Dragan Simic <dsimic@manjaro.org> writes:
> 
>> On 2023-09-03 05:43, Dragan Simic wrote:
>>> On 2023-09-03 00:16, Junio C Hamano wrote:
>>>> Having said all the above, once we start seeing the actual patches
>>>> and its sales pitch (aka proposed commit log message), we do guide
>>>> and help polishing the patch into a better shape, so it will not
>>>> be like the contributor has to work in the dark without knowing
>>>> what level of bar their contribution has to pass.
>>> Thanks, everything sounds great and welcoming to the new
>>> contributors,
>>> who of course need to be willing to put in the required amount of
>>> skill and effort.
>> 
>> I sent a patch to the git mailing list today, about five hours ago,
>> but it hasn't appeared on the list yet.  Could something be wrong with
>> the mail server(s), as I also received no other messages from the list
>> in the last six hours or so?
> 
> It is a high-volume mailing list server and occasional hiccup is
> part of regular life.  Waiting a bit and then poking the postmater
> at vger.kernel.org may be needed from time to time, but I am seeing
> your message on the archive, so it seems "waiting" has worked fine?

Yes, remaining patient did the trick this time.  A whole lot of messages 
from the list arrived at once after the hiccup resolved itself.