> > 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 I wouldn't get too exercised about this - the last person who did got barred from the list. The Git project's senior management are extremely strongly attached to not breaking Hyrum's Law. However obscure, or wrong, an interface is, someone will be relying on it if there is a sufficiently large user-base. Which there will be for Git, which must have millions of users (given GitHub has claimed a hundred million users). It is perhaps faintly possible that you could get agreement for a change with the next major version number. Or maybe an announcement that something would be deprecated and maybe the major version after that would change. Or maybe start producing a separate release series which can change this area but is distinctly separate from the glacially changing main line of releases. Regards, Richard.
