git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
	Phillip Wood <phillip.wood123@gmail.com>
Subject: Re: [PATCH v3] rebase: clarify conditionals in todo_list_to_strbuf()
Date: Fri, 11 Aug 2023 12:33:22 +0200	[thread overview]
Message-ID: <ZNYOco835hbiDZAC@ugly> (raw)
In-Reply-To: <xmqqleeihok5.fsf@gitster.g>

On Thu, Aug 10, 2023 at 09:03:54AM -0700, Junio C Hamano wrote:
>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


  reply	other threads:[~2023-08-11 10:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23 16:22 [PATCH] rebase: clarify conditionals in todo_list_to_strbuf() Oswald Buddenhagen
2023-03-23 20:32 ` Taylor Blau
2023-03-24  8:59   ` Oswald Buddenhagen
2023-03-24 14:39   ` Phillip Wood
2023-04-28 12:56 ` [PATCH v2] " Oswald Buddenhagen
2023-05-02 18:51   ` Felipe Contreras
2023-08-07 17:09   ` [PATCH v3] " Oswald Buddenhagen
2023-08-07 20:28     ` Junio C Hamano
2023-08-09 16:13       ` Oswald Buddenhagen
2023-08-09 19:39         ` Junio C Hamano
2023-08-10 12:08           ` Oswald Buddenhagen
2023-08-10 16:03             ` Junio C Hamano
2023-08-11 10:33               ` Oswald Buddenhagen [this message]
2023-08-11 11:41                 ` Richard Kerry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZNYOco835hbiDZAC@ugly \
    --to=oswald.buddenhagen@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=phillip.wood123@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).