Neeraj Singh <nksingh85@xxxxxxxxx> writes: > Just to understand your feedback better, is it a problem to separate > the state of each separate "thing" under ODB transactions into > separate file-scope global(s)? In this series I declared the fsync > state as completely separate from the packfile state. That's why I > was thinking of it as more of a naming problem, since the remaining > state aside from the plugged boolean is entirely packfile related. Ahh, sorry, my mistake. I somehow thought that you would be making the existing "struct bulk_checkin_state" infrastructure to cover not just the object store but much more, perhaps because I partly mistook the motivation to rename the structure (thinking again about it, since "checkin" is the act of adding new objects to the object database from outside sources (either from the working tree using "git add" command, or from other sources using unpack-objects), the original name was already fine to signal that it was about the object database, and the need to rename it sounded like we were going to do much more than the object database behind my head). > My argument in favor of having separate file-scoped variables for each > 'pluggable thing' would be that future implementations can evolve > separately without authors first having to disentangle a single > struct. That is fine. Would the trigger to "plug" and "unplug" also be independent? As you said elsewhere, the part to harden refs can piggyback on the existing ref-transaction infrastructure. I do not know offhand what things other than loose objects that want "plug" and "unplug" semantics, but if there are, are we going to have type specific begin- and end-transaction? Thanks.
