On 09/17/2014 12:22 AM, Jonathan Nieder wrote: > Michael Haggerty wrote: > >> If rename() fails, call rollback_lock_file() to delete the lock file >> (in case it is still present) and reset the filename field to the >> empty string so that the lockfile object is left in a valid state. > > Can you spell out more what the goal is? Is the idea to keep the > .lock file for a shorter period of time, so other processes can lock > that file before the current process exits? I doubt that there are situations where releasing the .lock file immediately vs. holding it until the end of the process makes any practical difference. Most callers die() right away if the commit fails. This change is more about cleaning up the API by making the state diagram for lock_file objects well-defined. commit_lock_file() can fail in multiple ways that callers cannot easily distinguish. So all of the failure paths have to leave the lock_file object in the same final state, otherwise the callers cannot know what state it is in. Since lock_file objects are reusable, this is an API design bug. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html