From: Phillip Wood <phillip.wood123@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Usman Akinyemi <usmanakinyemi202@gmail.com>,
Usman Akinyemi via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH v2] diff: update conflict handling for whitespace to issue a warning
Date: Tue, 19 Nov 2024 16:49:05 +0000 [thread overview]
Message-ID: <dc092d9e-d95c-4635-b4f9-85cf1802e571@gmail.com> (raw)
In-Reply-To: <xmqqbjyh5pa5.fsf@gitster.g>
On 15/11/2024 00:11, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
>> Usman - when you're writing a commit message it is important to
>> explain the reason for making the changes contained in the patch so
>> others can understand why it is a good idea. In this case the idea is
>> to avoid breaking "git diff" for everyone who clones a repository
>> containing a .gitattributes file with bad whitespace attributes
>> [1].
>
> Hmph, it would certainly be a problem, but the right solution is not
> to butcher Git, but to make it easier for the participants of such a
> project to know what is broken *and* what needs to be updated, to let
> them move forward, no?
Arguably yes, but that's not the approach we take when the attributes
file is too large, a line in the file is is too long or the file
contains a negative filename pattern. For those cases we print a warning
and continue. The recently merged e36f009e69b (merge: replace atoi()
with strtol_i() for marker size validation, 2024-10-24) followed suit
and warns rather than dies for an invalid marker size. It would be nice
to be consistent in the way we treat invalid attributes. Consistently
dying and telling the user how to fix the problem would be a reasonable
approach on the client side but I wonder if it could cause problems for
forges running "git diff" and "git merge-tree" on a server though.
> [...]
> If we were to fix anything, it is to make sure that we die() before
> producing a single line of output.
That would certainly be a good idea
Best Wishes
Phillip
next prev parent reply other threads:[~2024-11-19 16:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 17:49 [PATCH] diff: update conflict handling for whitespace to issue a warning Usman Akinyemi via GitGitGadget
2024-11-11 23:59 ` Junio C Hamano
2024-11-13 19:01 ` [PATCH v2] " Usman Akinyemi via GitGitGadget
2024-11-14 2:15 ` Junio C Hamano
2024-11-14 10:06 ` Phillip Wood
2024-11-14 11:29 ` Usman Akinyemi
2024-11-15 0:11 ` Junio C Hamano
2024-11-18 21:03 ` Usman Akinyemi
2024-11-19 0:36 ` Junio C Hamano
2024-11-19 16:49 ` Phillip Wood [this message]
2024-11-20 1:23 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dc092d9e-d95c-4635-b4f9-85cf1802e571@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
--cc=usmanakinyemi202@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.
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 NNTP newsgroup(s).