On Thu, Aug 10, 2023 at 09:03:54AM -0700, Junio C Hamano wrote:
Oswald Buddenhagen <oswald.buddenhagen@xxxxxx> writes:
On Wed, Aug 09, 2023 at 12:39:37PM -0700, Junio C Hamano wrote:
Thanks. Then this patch is still a strict "Meh" to me.
i can't really think of a reason why you reject such a no-brainer
other than that you consider it churn. in that case i need to tell you
that you have unreasonable standards, which actively contribute to the
code remaining a mess.
An ad-hominem remark is a signal that it is good time to disengage.
i'm pointing out what i consider a systematic mistake. there is no way
of doing that in a way that isn't somewhat personal.
the thing is that after _such_ an experience, no sane person would ever
invest into something that falls under pure code maintenance in this
project again. is that really what you want?
There are certain style differences that may be acceptable if it
were written from the get-go,
it's not just a style difference. it clarifies the code semantically,
and potentially shrinks the executable a bit.
but it is not worth the patch churn to switch once it is in the tree.
what is the problem _exactly_?
the time it takes to discuss such patches? the solution would be not
bike-shedding them to death.
process overhead in applying them? then it's time to amend the process
and/or tooling to accomodate trivial changes better.
minimizing history size and preserving git blame? then rethink your
priorities. i'm rather OCD about this myself and would usually reject
random style cleanups, but the actual experience is that a few "noise"
commits don't really get into the way of doing archeology - searching in
variations of `git log -p` and using "blame parent revision" in
interactive tools are usually required anyway. saving a few seconds in
this process really isn't worth keeping the current code messier than
necessary.
anything else?
regards
