Eric Wong [off-list ref] writes:
Lars Schneider [off-list ref] wrote:
quoted
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.
On 13 May 2016, at 18:37, Junio C Hamano [off-list ref] wrote:
Eric Wong [off-list ref] writes:
quoted
Lars Schneider [off-list ref] wrote:
quoted
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.
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?)
Most Recent Commands Before Crash
---------------------------------
commit refs/remotes/p4/master
mark :1
committer Dr. author [off-list ref] 1463212118 +0000
data <<EOT
M 100644 inline f1
data 3
commit refs/remotes/p4/master
mark :2
committer Dr. author [off-list ref] 1463212118 +0000
data <<EOT
M 100644 inline f2
data 3
commit refs/remotes/p4/master
mark :4
committer Dr. author [off-list ref] 1463212118 +0000
data <<EOT
M 100644 inline f4
data 3
checkpoint
commit git-p4-tmp/6
mark :6
committer Dr. author [off-list ref] 1463212118 +0000
data <<EOT
M 100644 inline f1
data 3
M 100644 inline f2
data 3
M 100644 inline f4
data 3
checkpoint
progress checkpoint
commit refs/remotes/p4/depot/branch2
mark :6
committer Dr. author [off-list ref] 1463212118 +0000
data <<EOT
from 1ab0d5b43b6070682f8bd6f3fd674d4fcddd9345
* M 100644 inline f1
Active Branch LRU
-----------------
active_branches = 2 cur, 5 max
pos clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 4 git-p4-tmp/6
2) 3 refs/remotes/p4/master
Inactive Branches
-----------------
git-p4-tmp/6:
status : active loaded
tip commit : 3aef1b3e7d821051780a89262f2e2fae33ed8af3
old tree : 30a8495449245cdb9626ef48902ba672cf76576f
cur tree : 30a8495449245cdb9626ef48902ba672cf76576f
commit clock: 4
last pack : 0
refs/remotes/p4/master:
status : active loaded
tip commit : 1ab0d5b43b6070682f8bd6f3fd674d4fcddd9345
old tree : 30a8495449245cdb9626ef48902ba672cf76576f
cur tree : 30a8495449245cdb9626ef48902ba672cf76576f
commit clock: 3
last pack : 0
refs/remotes/p4/depot/branch2:
status : loaded
tip commit : 1ab0d5b43b6070682f8bd6f3fd674d4fcddd9345
old tree : 30a8495449245cdb9626ef48902ba672cf76576f
cur tree : 30a8495449245cdb9626ef48902ba672cf76576f
commit clock: 0
last pack :
Marks
-----
:1 47474c2e749d579c63b375231c018289aa00cd0f
:2 9c6b957c0b4d4991b8bbd17858aa2a271d2c76c3
:4 1ab0d5b43b6070682f8bd6f3fd674d4fcddd9345
:6 3aef1b3e7d821051780a89262f2e2fae33ed8af3
-------------------
END OF CRASH REPORT
quoted
The easiest change is probably to call:
git config fastimport.unpackLimit 0
during setup like t9300 now does.
Unfortunately that seems not to help.
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.
Cheers,
Lars