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

Re: [BUG] t9801 and t9803 broken on next

From
Luke Diamand <luke@diamand.org>
Date
May 17, 2016, 08:35 UTC
Message-ID
<CAE5ih79qUv237GXfW24HdJrx0WBiK4uvuWXe+d3v7NiOVtwHGQ@mail.gmail.com>
In-Reply-To
<xmqq37pk8q0h.fsf@gitster.mtv.corp.google.com>
On 14 May 2016 at 19:15, Junio C Hamano <gitster@pobox.com> wrote:
Show 37 quoted lines
> Lars Schneider <larsxschneider@gmail.com> writes:
>
>>> On 13 May 2016, at 18:37, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> Are you saying that "git p4" itself breaks unless fast-import always
>>> writes a new (tiny) packfile?  That sounds quite broken, and setting
>>> unpacklimit to 0 does not sound like a sensible "fix".  Of course,
>>> if the test script is somehow looking at the number of packs or
>>> loose objects and declaring a failure, even when the resulting
>>> history in p4 and git are correct, then that is a different issue,
>>> and forcing to explode a tiny pack is a reasonable workaround.  I
>>> couldn't quite tell which the case is.
>>>
>>> Puzzled.  Please help.
>>
>> t9801 "import depot, branch detection" is the first test that fails
>> with a fast import error:
>> https://github.com/git/git/blob/78b384c29366e199741393e56030a8384110760d/t/t9801-git-p4-branch.sh#L110
>>
>> fast-import crash report:
>>     fast-import process: 77079
>>     parent process     : 77077
>>     at 2016-05-14 07:48:40 +0000
>>
>> fatal: offset beyond end of packfile (truncated pack?)
>
> Hmm, does that suggest Eric's "explode them into loose instead of
> keeping a small pack" insufficient?  It sounds like that somebody
> wanted to read some data back from its packfile without knowing that
> the updated code may make it available in a loose object form, which
> would mean that somebody needs to be told about what is going on,
> namely, these objects are not in a half-written pack but are found
> as loose objects.
>
>> The problem seems to be related to the git-p4 branch import.
>> I don't have time this weekend to look further into it, but
>> I will try next week.
The last thing that fast-import is sent before it crashes is this:
checkpoint
  progress checkpoint
  commit refs/remotes/p4/depot/branch2
  mark :6
  committer Dr. author <author@example.com> 1463212118 +0000
  data <<EOT
  from 1ab0d5b43b6070682f8bd6f3fd674d4fcddd9345

i.e. creating a new branch, referring to an existing object. Is it possible that fast-import can't find 1ab0d... because of the reasons given by Junio above? I don't know enough about fast-import tbh.

I will see if I can get fast-import to tell me a bit more about why it's failing.

Luke
Previous: Jeff King
Message 19 of 19 in “[BUG] t9801 and t9803 broken on next”
  1. Lars SchneiderMay 13, 2016
  2. Eric WongMay 13, 2016
  3. Junio C HamanoMay 13, 2016
  4. Lars SchneiderMay 14, 2016
  5. Junio C HamanoMay 14, 2016
  6. Lars SchneiderMay 17, 2016
  7. Eric WongMay 17, 2016
  8. Jeff KingMay 17, 2016
  9. Lars SchneiderMay 19, 2016
  10. Junio C HamanoMay 19, 2016
  11. Lars SchneiderMay 19, 2016
  12. Eric WongMay 25, 2016
  13. [RFC] fast-import: invalidate pack_id references after looseningEric Wong, May 25, 2016
  14. Jeff KingMay 25, 2016
  15. Eric WongMay 26, 2016
  16. Jeff KingMay 26, 2016
  17. Eric WongMay 28, 2016
  18. Jeff KingMay 25, 2016
  19. Luke DiamandMay 17, 2016

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.