From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Joey Hess <id@joeyh.name>,
git@vger.kernel.org
Subject: Re: [PATCH 00/12] Fix various overly aggressive protections in 2.45.1 and friends
Date: Tue, 28 May 2024 10:47:04 -0700 [thread overview]
Message-ID: <xmqqzfs94ynb.fsf@gitster.g> (raw)
In-Reply-To: <8353645a-a684-417a-8b0e-d8cbd7da6b5a@gmail.com> (Phillip Wood's message of "Tue, 28 May 2024 16:02:37 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
>> And there is a good reason _not_ to write stuff inside the `.git/`
>> directory unless you happen to be, well, Git itself: Git makes no
>> guarantees whatsoever that you can write into that directory whatever you
>> want. A future Git version might even write a file `.git/annex`, breaking
>> `git-annex`' assumptions, and that'd be totally within the guarantees Git
>> makes.
>
> This seems a bit harsh - many tools store their state under .git/ and
> I think it makes sense for them to do so as it avoids creating
> untracked files in the working copy. I would hope that we'd be
> considerate of widely used tools such as 'git annex' when adding new
> paths under .git/
Yes, a .git/annex file _can_ happen, but between civilized developer
groups, such a thing would not happen without a good reason. If we
have no good reason (apparently you and I did not think of any) to
create such a file, "it can happen" is a poor straw-man, as we would
be aiming to work well together.
Yes, when we have a symbolic link as a tracked content, updating the
target of the link when we need to update it is simply a bug, and it
does not matter if it points at a file inside our own repository, or
a file inside a different and unrelated repository that is owned by
the same user, or a file in the user's home directory. Our own
repository is not all that special from that perspective, and a
change to penalize symbolic links that point into our repository
specifically probably did make a bad choice.
Thanks.
next prev parent reply other threads:[~2024-05-28 17:47 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 [this message]
2024-05-23 23:32 ` 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=xmqqzfs94ynb.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=id@joeyh.name \
--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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.