Re: [BUG] t9801 and t9803 broken on next
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 13, 2016, 16:37 UTC
- Message-ID
- <xmqqpospap8g.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <20160513103621.GA12329@dcvr.yhbt.net>
Eric Wong <e@80x24.org> writes:
Show 10 quoted lines
> Lars Schneider <larsxschneider@gmail.com> 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.
Show 5 quoted lines
> The easiest change is probably to call: > > git config fastimport.unpackLimit 0 > > during setup like t9300 now does.