Re: [RFC 0/1] Tolerate broken headers in `packed-refs` files

From: Derrick Stolee <stolee@gmail.com>
Date: Mar 26, 2018, 13:08 UTC
Message-ID: <f8d0f3b6-69b3-ba42-c39c-551814caf335@gmail.com>
In-Reply-To: <cover.1522062649.git.mhagger@alum.mit.edu>

On 3/26/2018 8:42 AM, Michael Haggerty wrote:

Show 17 quoted lines

> [...]
>
> But there might be some tools out in the wild that have been writing
> broken headers. In that case, users who upgrade Git might suddenly
> find that they can't read repositories that they could read before. In
> fact, a tool that we wrote and use internally at GitHub was doing
> exactly that, which is how we discovered this "problem".
>
> This patch shows what it would look like to relax the parsing again,
> albeit *only* for the first line of the file, and *only* for lines
> that start with '#'.
>
> The problem with this patch is that it would make it harder for people
> who implement broken tools in the future to discover their mistakes.
> The only result of the error would be that it is slower to work with
> the `packed-refs` files that they wrote. Such an error could go
> undiscovered for a long time.

My opinion is that we shouldn't maintain back-compat with formats that may have been written by another tool because Git wasn't strict about it. As long as Git never wrote files with these formats, then they shouldn't be supported.

You are absolutely right that staying strict will help discover the tools that are writing an incorrect format.

Since most heavily-used tools that didn't spawn Git processes use LibGit2 to interact with Git repos, I added Ed Thomson to CC to see if libgit2 could ever write these bad header comments.

Thanks for writing this RFC so we can have the discussion and more quickly identify this issue if/when users are broken.

Thanks, -Stolee