Re: [PATCH v4 1/7] refs: accept symref values in `ref_transaction[_add]_update`
- From
- phillip.wood123@gmail.com <phillip.wood123@gmail.com>
- Date
- Apr 29, 2024, 09:29 UTC
- Message-ID
- <ea3ee800-af0c-46e5-9032-391d82a4f046@gmail.com>
- In-Reply-To
- <20240429075524.GA3908618@coredump.intra.peff.net>
On 29/04/2024 08:55, Jeff King wrote:
Show 17 quoted lines
> On Mon, Apr 29, 2024 at 09:02:56AM +0200, Patrick Steinhardt wrote: > >> In any case, I very much agree that git-update-ref(1) should refuse to >> write refs with names that are known-bad. There should probably be an >> escape hatch though that at least allows you to _delete_ those, or >> otherwise there is no way to remove such a ref in the reftable repo. >> Well, except for meddling with the binary format, but I doubt that >> anybody would really want to do that. > > Yeah, ironically deleting is the one thing you cannot do with them even > right now. ;) That is because the supposedly-looser refname_is_safe() is > actually tighter. > > It would be tough to loosen it safely, since you don't want to allow > deleting arbitrary files in .git. Or worse, escaping .git via clever > paths, symlinks, etc. So I think at most you'd want some kind of "trust > me, for this command don't bother with ref format checks" flag.
Currently "git update-ref config HEAD" fails because the config file does not look like a ref - could we do similar check when deleting references at least for the files backend for arguments outside refs/?
Best Wishes
Phillip