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

Re: [BUG] refs: verify does not work if there are v2.43.0 or older worktrees w/o wt. refs

From
Kristoffer Haugsbakk <code@khaugsbakk.name>
Date
May 31, 2025, 09:52 UTC
Message-ID
<a2a50127-6ab9-4d8a-abcc-b1a741df293e@app.fastmail.com>
In-Reply-To
<CAPig+cQiw03qfwwE9Md+LdKeS-6BGx0M1+0YYDUDXO9UPVo+wg@mail.gmail.com>
On Sat, May 31, 2025, at 00:23, Eric Sunshine wrote:
Show 9 quoted lines
>> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>> Subject: [PATCH] t0602: demo v2.43.0 worktree problem
>>
>> Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
>
> Even though this is a bug report and the patch you included doesn't
> provide a fix, you did craft a couple tests, presumably with the
> intention that they should be used by whomever fixes the problem. As
> such, I'll give them a bit of a critique...

Yes if s/should/could.[1] These are reproduction scripts as patches. So they can be applied and show the current state (first test is expect-failed, the second is expect-success) of the code.

My previous reproduction script with the git-clone(1) is inconvenient but either cloning or using a worktree is necessary in order to truly reproduce the problem (as opposed to simulating it).

A `-subject-prefix='PATCH THROWAWAY'` would have been in order.

On the other hand I did write the first test (the second is ugly) as if I was doing a quote-unquote real patch. In that light learning more about the proper style is useful for me. So thanks for the review!

> Overall, although the first new test makes sense, it is not at all
> clear to me what the second test is checking or what its purpose is.

The idea behind the second test was to show a case where it does work with old worktrees. But simulating the old worktree didn’t make sense since it looks just like a new worktree when there *are* indeed worktree refs. So it just ended up being confusing.

† 1: As in troubleshooting and fixing the problem, not the final test in
    the submitted patch.  The test is unlikely to be good enough for
    that.  But the patch is signed off on the small chance that it can
    be used because why not.
Previous: shejialuoNext: shejialuo
Message 4 of 21 in “[BUG] refs: verify does not work if there are v2.43.0 or older worktrees w/o wt. refs”
  1. kristofferhaugsbakk@fastmail.comMay 30, 2025
  2. Eric SunshineMay 30, 2025
  3. shejialuoMay 31, 2025
  4. Kristoffer HaugsbakkMay 31, 2025
  5. fsck: ignore missing "refs" directory for linked worktreesshejialuo, May 31, 2025
  6. Kristoffer HaugsbakkMay 31, 2025
  7. Junio C HamanoJun 2, 2025
  8. shejialuoJun 2, 2025
  9. Phillip WoodJun 2, 2025
  10. Patrick SteinhardtJun 2, 2025
  11. phillip.wood123@gmail.comJun 2, 2025
  12. Junio C HamanoJun 2, 2025
  13. shejialuoJun 2, 2025
  14. shejialuoJun 2, 2025
  15. 0/1 [BUG] refs: verify does not work if there are v2.43.0 or older worktrees w/o wt. refsshejialuo, Jun 2, 2025
  16. 1/1 fsck: ignore missing "refs" directory for linked worktreesshejialuo, Jun 2, 2025
  17. Kristoffer HaugsbakkJun 2, 2025
  18. shejialuoJun 2, 2025
  19. 0/1 [BUG] refs: verify does not work if there are v2.43.0 or older worktrees w/o wt. refsshejialuo, Jun 2, 2025
  20. 1/1 fsck: ignore missing "refs" directory for linked worktreesshejialuo, Jun 2, 2025
  21. Kristoffer HaugsbakkJun 2, 2025

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.