"Neeraj Singh via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Neeraj Singh <neerajsi@xxxxxxxxxxxxx> > > Preparation for adding bulk-fsync to the bulk-checkin.c infrastructure. > > * Rename 'state' variable to 'bulk_checkin_state', since we will later > be adding 'bulk_fsync_objdir'. This also makes the variable easier to > find in the debugger, since the name is more unique. > > * Move the 'plugged' data member of 'bulk_checkin_state' into a separate > static variable. Doing this avoids resetting the variable in > finish_bulk_checkin when zeroing the 'bulk_checkin_state'. As-is, we > seem to unintentionally disable the plugging functionality the first > time a new packfile must be created due to packfile size limits. While > disabling the plugging state only results in suboptimal behavior for > the current code, it would be fatal for the bulk-fsync functionality > later in this patch series. Sorry, but I am confused. The bulk-checkin infrastructure is there so that we can send many little objects into a single packfile instead of creating many little loose object files. Everything we throw at object-file.c::index_stream() will be concatenated into the single packfile while we are "plugged" until we get "unplugged". My understanding of what you are doing in this series is to still create many little loose object files, but avoid the overhead of having to fsync them individually. And I am not sure how well the original idea behind the bulk-checkin infrastructure to avoid overhead of having to create many loose objects by creating a single packfile (and presumably having to fsync at the end, but that is just a single .pack file) with your goal of still creating many loose object files but synching them more efficiently. Is it just the new feature is piggybacking on the existing bulk checkin infrastructure, even though these two have nothing in common?
