From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, Joey Hess <id@joeyh.name>
Subject: Re: [PATCH 00/12] Fix various overly aggressive protections in 2.45.1 and friends
Date: Thu, 23 May 2024 16:32:25 -0700 [thread overview]
Message-ID: <xmqqy180p0ja.fsf@gitster.g> (raw)
In-Reply-To: <xmqqv835xekc.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 22 May 2024 22:49:55 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Joey Hess <id@joeyh.name> writes:
>
>> Please also revert it, or at least the portions for
>> and symlinkPointsToGitDir and symlinkTargetLength. The
>> checks for symlinkTargetBlob and symlinkTargetMissing seem worth
>> keeping.
>
> Looking at the change in question, in a33fea08 (fsck: warn about
> symlink pointing inside a gitdir, 2024-04-10), you said:
> ...
> So, I am ambivalent. I have prepared a revert queued on maint-2.39
> and cascaded it up to the maintenance track, which I tentatively
> queued on top of 'seen', to see how much damage such a reversion
> involves (and it did not look too bad), but
>
> (1) I am not sure if this is such a huge deal that requires a
> revert;
>
> (2) I am not sure which one is more practical between ripping
> everything out and demoting these new fsck error types with
> FSCK_WARN to FSCK_IGNORE. If the structure of the code to
> perform these checks is more or less good and the actual check
> the code implements is bad, the latter might give us a better
> foundation to build on than rebuilding everything from scratch.
> On the other hand, if we are redoing things in the open, it may
> be better to forget about the code in 2.45.1/2.39.4 and to build
> from scratch for those reviewers and developers who will offer
> help.
>
> (3) As I look at the change by a33fea08 again, it actually adds a
> few new fsck error types with FSCK_ERROR. Perhaps that is a
> good enough reason to do a straight revert for now?
>
> Thanks. It is past my bedtime so I won't be pushing out the 'seen'
> with the revert I prepared as a practice, at least tonight.
So at least for now, I've queued a full revert of the change in
question in the "revert over-eager layering-on-top changes" pile,
but as we haven't really seen anybody give good input to help me
decide what to do with this step, the pile is still kept outside of
the 'next' branch. At least it is visible on 'seen' as of tonight.
Thanks.
prev parent reply other threads:[~2024-05-23 23:32 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-21 19:56 [PATCH 00/12] Fix various overly aggressive protections in 2.45.1 and friends Junio C Hamano
2024-05-21 19:56 ` [PATCH 01/12] send-email: drop FakeTerm hack Junio C Hamano
2024-05-22 8:19 ` Dragan Simic
2024-05-21 19:56 ` [PATCH 02/12] send-email: avoid creating more than one Term::ReadLine object Junio C Hamano
2024-05-22 8:15 ` Dragan Simic
2024-05-21 19:56 ` [PATCH 03/12] ci: drop mention of BREW_INSTALL_PACKAGES variable Junio C Hamano
2024-05-21 19:56 ` [PATCH 04/12] ci: avoid bare "gcc" for osx-gcc job Junio C Hamano
2024-05-21 19:56 ` [PATCH 05/12] ci: stop installing "gcc-13" for osx-gcc Junio C Hamano
2024-05-21 19:56 ` [PATCH 06/12] hook: plug a new memory leak Junio C Hamano
2024-05-21 19:56 ` [PATCH 07/12] init: use the correct path of the templates directory again Junio C Hamano
2024-05-21 19:56 ` [PATCH 08/12] Revert "core.hooksPath: add some protection while cloning" Junio C Hamano
2024-05-21 19:56 ` [PATCH 09/12] tests: verify that `clone -c core.hooksPath=/dev/null` works again Junio C Hamano
2024-05-21 22:57 ` Brooke Kuhlmann
2024-05-21 19:56 ` [PATCH 10/12] clone: drop the protections where hooks aren't run Junio C Hamano
2024-05-21 19:56 ` [PATCH 11/12] Revert "Add a helper function to compare file contents" Junio C Hamano
2024-05-21 19:56 ` [PATCH 12/12] Revert "fetch/clone: detect dubious ownership of local repositories" Junio C Hamano
2024-05-21 20:43 ` Junio C Hamano
2024-05-22 7:27 ` Johannes Schindelin
2024-05-22 17:20 ` Junio C Hamano
2024-05-21 20:45 ` [rPATCH 13/12] Merge branch 'jc/fix-aggressive-protection-2.39' Junio C Hamano
2024-05-23 10:36 ` Reviewing merge commits, was " Johannes Schindelin
2024-05-23 14:41 ` Junio C Hamano
2024-05-21 20:45 ` [rPATCH 14/12] Merge branch 'jc/fix-aggressive-protection-2.40' Junio C Hamano
2024-05-21 21:33 ` Junio C Hamano
2024-05-21 21:14 ` [PATCH 00/12] Fix various overly aggressive protections in 2.45.1 and friends Johannes Schindelin
2024-05-21 21:46 ` Junio C Hamano
2024-05-21 22:13 ` Junio C Hamano
2024-05-22 10:01 ` Joey Hess
2024-05-23 5:49 ` Junio C Hamano
2024-05-23 16:31 ` Joey Hess
2024-05-27 19:51 ` Johannes Schindelin
2024-05-28 2:25 ` Joey Hess
2024-05-28 15:02 ` Phillip Wood
2024-05-28 16:13 ` Junio C Hamano
2024-05-28 17:47 ` Junio C Hamano
2024-05-23 23:32 ` Junio C Hamano [this message]
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=xmqqy180p0ja.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=id@joeyh.name \
/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).