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

On Mon, Mar 26, 2018 at 2:08 PM, Derrick Stolee wrote: > 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. We added the `sorted`

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

On Mon, Mar 26, 2018 at 09:08:04AM -0400, Derrick Stolee wrote: > 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. Ed can probably answer more

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

On 3/26/2018 8:42 AM, Michael Haggerty wrote: [...] 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

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

Prior to 9308b7f3ca read_packed_refs(): die if `packed-refs` contains bogus data, 2017-07-01 we silently ignored pretty much any bogus data in a `packed-refs` file. I think that was pretty clearly a bad policy. The above commit made parsing quite a bit stricter, calling `die()` if it found