Re: [PATCH v3] rebase: clarify conditionals in todo_list_to_strbuf()

From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date: Aug 11, 2023, 10:33 UTC
Message-ID: <ZNYOco835hbiDZAC@ugly>
In-Reply-To: <xmqqleeihok5.fsf@gitster.g>

On Thu, Aug 10, 2023 at 09:03:54AM -0700, Junio C Hamano wrote:

Show 12 quoted lines

>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> 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