Derrick Stolee <stolee@xxxxxxxxx> writes: > This makes sense as a feature, except that we need to write the number > of objects present in a packfile in its header. If we wanted to avoid > the argument, then we'd need to load the data into a list before > starting to write the packfile. By taking the count in advance, the > implementation is simpler. Perhaps, but in the production code we already seek back and update the header after writing a packfile with fixup_pack_header_footer(), so which shoulnd't be too much work conceptually. You earlier said something about faster development cycles; not having to figure out how to seek back and fix the header does help faster development of this helper ;-). >> One thing it lets >> us do to have this as a separate number is to create an invalid pack >> stream where the header gives a wrong number, and as a test tool, >> that may trump the convenience of not having to give the number >> explicitly. > But also, this allows generating bad packfiles which is a bonus. > A very good point. If this were an end-user facing program, we would most likely let it count but let the count be overridden by the command line argument. But until then, as I said, I am fine to just declare that it is just a test helper ;-) Thanks.