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

Re: "Cannot fetch git.git" (worktrees at fault? or origin/HEAD) ?

From
Stefan Beller <sbeller@google.com>
Date
Oct 20, 2017, 20:45 UTC
Message-ID
<CAGZ79kaeJsahVuWgFsJfyGahciT4xBeM3m59F5crGy4+ZRJMCw@mail.gmail.com>
In-Reply-To
<20171020060443.l6v74ik4v4jdt4ky@sigill.intra.peff.net>
On Thu, Oct 19, 2017 at 11:04 PM, Jeff King <peff@peff.net> wrote:
Show 14 quoted lines
> On Thu, Oct 19, 2017 at 10:27:28PM -0700, Stefan Beller wrote:
>
>> > If my analysis above is correct, then it's already fixed. You just had
>> > leftover corruption.
>>
>> Well fetching yesterday worked and the commit in question is from
>> 8/23, the merge  8a044c7f1d56cef657be342e40de0795d688e882
>> occurred 9/18, so I suspect there is something else at play.
>> (I do not remember having a gc between yesterday and today.
>> Though maybe one in the background?)
>
> Even a gc between yesterday and today should have used the new code,
> which would have been safe. So yeah, maybe it is something else
> entirely.
Oh, yeah.
Show 29 quoted lines
>
>> I am curious how you can have a worktree owned by multiple
>> repositories [1] (?).
>
> Sorry, I forgot my footnote. I saw this with my "ci" script:
>
>   https://github.com/peff/git/blob/7905ff395adecdd2bb7ab045a24223dfb103e0e9/ci
>
> I check out the contents of my "meta" branch as "Meta", and it contains
> that script. It basically just waits for ref updates, then walks over
> all the commits and runs "make test" on them in the background (caching
> the results, thanks to the git-test[1] script). So I kick off "Meta/ci"
> in a terminal and forget about it, and magically it builds my commits in
> the background as I work.
>
> It operates in a worktree inside the Meta directory (Meta/tmp-ci), so as
> not to disturb what I'm doing. So far so good.
>
> But I actually have _two_ clones of Git on my system. One on which I do
> most of my work, and then the other which has the fork we use in
> production at GitHub. I symlink the Meta directory from the first into
> the latter, which means they both see the same worktree directory. And
> somehow running "Meta/ci" in the second corrupted things.
>
> I can get some funniness now, but I think it's mostly caused by the
> script being confused about the worktree existing but not having access
> to our branches. That's not a corruption, just a confusion. I _think_ I
> had a bogus HEAD in the worktree at one point, but I may be
> mis-remembering. I can't seem to trigger it now.
Thanks for these insights.

I played around with Meta a bit, but I did not feel it would enhance my workflow enough as I am not involved with any maintainance of git using git.

The git-test from Michael sounds intriguing. Initially I put off using it as I had my main working dir (or rather test dir) on a spinning disk, still. Now I test in memory only, which is a lot faster, so I could try if git-test can keep up with my local commit pace.

Thanks, Stefan

Previous: Jeff KingNext: Kaartic Sivaraam
Message 5 of 11 in “"Cannot fetch git.git" (worktrees at fault? or origin/HEAD) ?”
  1. Stefan BellerOct 20, 2017
  2. Jeff KingOct 20, 2017
  3. Stefan BellerOct 20, 2017
  4. Jeff KingOct 20, 2017
  5. Stefan BellerOct 20, 2017
  6. Kaartic SivaraamOct 22, 2017
  7. Jeff KingOct 23, 2017
  8. Stefan BellerOct 23, 2017
  9. Kaartic SivaraamNov 3, 2017
  10. Stefan BellerNov 3, 2017
  11. Kaartic SivaraamNov 7, 2017

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.