Eric Wong <e@xxxxxxxxx> writes: > Lars Schneider <larsxschneider@xxxxxxxxx> wrote: >> Hi, >> >> t9801 and t9803 seem to be broken on next. A quick bisect indicates that d9545c7 >> "fast-import: implement unpack limit" might be the reason. (@gmane/292562). >> >> Did anyone look into that already? > > Just took a look (no p4, so couldn't run tests) and I guess it's > because the default changed and it doesn't generate tiny packs. I looked at t9801 but I couldn't spot where it cares if the objects are in a (tiny) pack or stored as individual loose objects. All the counting I saw was about rev-list/log output and they shouldn't care. 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. > The easiest change is probably to call: > > git config fastimport.unpackLimit 0 > > during setup like t9300 now does. -- 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