Re: [PATCH v6 4/9] packed-backend: check if header starts with "# pack-refs with: "

From: Patrick Steinhardt <ps@pks.im>
Date: Feb 26, 2025, 08:08 UTC
Message-ID: <Z77MAMqVGrT2jgcf@pks.im>
In-Reply-To: <Z73D5XLzzg-OPmdT@ArchLinux>

On Tue, Feb 25, 2025 at 09:21:41PM +0800, shejialuo wrote:

Show 17 quoted lines

> We always write a space after "# pack-refs with:". However, when
> creating the packed-ref snapshot, we only check whether the header
> starts with "# pack-refs with:". However, we need to make sure that we
> would not break compatibility by tightening the rule. The following is
> how some third-party libraries handle the header of "packed-ref" file.
> 
> 1. libgit2 is fine and always writes the space. It also expects the
>    whitespace to exist.
> 2. JGit does not expect th header to have a trailing space, but expects
>    the "peeled" capability to have a leading space, which is mostly
>    equivalent because that capability is typically the first one we
>    write. It always writes the space.
> 3. gitoxide expects the space t exist and writes it.
> 4. go-git doesn't create the header by default.
> 
> So, we are safe to tighten the rule by checking whether the header
> starts with "# pack-refs with: ".

The commit message nicely describes why it's safe to do the change, but it doesn't describe why it's something we _want_ to do.

Ideally, we'd be able to argue with a technical spec of the format, but unless I'm mistaken such a document does not exist. The next-best thing is to do what everyone can agree on, and that seems to be to both write and expect a space after the colon. By not following consensus that exists in other libraries we're being more loose.

So if we for example started to stop writing the space due to a bug, we'd still continue to parse the header alright and thus not notice the problem, but now we have broken other implementations. That may be a good enough justification for the change itself.

Patrick