Stefan Beller <sbel...@google.com> writes: > By closing the file descriptors after creating the lock file we are not > limiting the size of the transaction by the number of available file > descriptors. > > When closing the file descriptors early, we also need to write the values > in early, if we don't want to reopen the files.
I am not sure if an early return in write_ref_sha1() is entirely correct. The unlock step was split out of write and commit functions in the previous step because you eventually want to be able to close the file descriptor that is open to $ref.lock early, while still keeping the $ref.lock file around to avoid others competing with you, so that you can limit the number of open file descriptors, no? If so, shouldn't the write function at least close the file descriptor even when it knows that the $ref.lock already has the correct object name? The call to close_ref() is never made when the early-return codepath is taken as far as I can see. Puzzled... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
