git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Mar 26, 2018, 12:42 UTC
Message-ID
<cover.1522062649.git.mhagger@alum.mit.edu>
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 any lines that it didn't understand.

But there's one situation that is maybe not quite so clear-cut. The first line of a `packed-refs` file can be a header that enumerates some traits of the file containing it; for example,

    # pack-refs with: peeled fully-peeled 

The old code would have tolerated lots of breakage in that line. For example, any of the following headers would have just been ignored:

    # arbitrary data that looks like a comment
    # pack-refs with peeled fully-peeled          ← note: missing colon
    # pack-refs

Now, any of the above lines are considered errors and cause git to die.

In my opinion, that is a good thing and we *shouldn't* tolerate broken header lines; i.e., the status quo is good and we *shouldn't* apply this patch.

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.

The tighter check was released quite a while ago, and AFAIK we haven't had any bug reports from people tripped up by this consistency check. So I'm inclined to believe that the existing tools are OK and this patch would be counterproductive. But I wanted to share it with the list anyway.

Michael
Michael Haggerty (1):
  packed-backend: ignore broken headers
 refs/packed-backend.c | 21 +++++++++------------
 t/t3210-pack-refs.sh  | 33 ++++++++++++++++++++++++++++++++-
 2 files changed, 41 insertions(+), 13 deletions(-)
-- 
2.14.2
Next: Michael Haggerty
Message 1 of 5 in “[RFC 0/1] Tolerate broken headers in `packed-refs` files”
  1. Michael HaggertyMar 26, 2018
  2. 1/1 packed-backend: ignore broken headersMichael Haggerty, Mar 26, 2018
  3. Derrick StoleeMar 26, 2018
  4. Jeff KingMar 26, 2018
  5. Edward ThomsonMar 26, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.