Lars Schneider <larsxschneider@xxxxxxxxx> writes: >> On 13 May 2016, at 18:37, Junio C Hamano <gitster@xxxxxxxxx> 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. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html