On 11/05/2014 03:23 AM, Scott Schmit wrote: > On Sun, Nov 02, 2014 at 07:24:37AM +0100, Michael Haggerty wrote: >> Locked paths can be saved in a linked list so that if something wrong >> happens, *.lock are removed. For relative paths, this works fine if we >> keep cwd the same, which is true 99% of time except: >> >> - update-index and read-tree hold the lock on $GIT_DIR/index really >> early, then later on may call setup_work_tree() to move cwd. >> >> - Suppose a lock is being held (e.g. by "git add") then somewhere >> down the line, somebody calls real_path (e.g. "link_alt_odb_entry"), >> which temporarily moves cwd away and back. >> >> During that time when cwd is moved (either permanently or temporarily) >> and we decide to die(), attempts to remove relative *.lock will fail, >> and the next operation will complain that some files are still locked. >> >> Avoid this case by turning relative paths to absolute before storing >> the path in "filename" field. > > This might be a little pathological, but it seems like this scheme would > run into trouble if the entire repo is moved while the lock is held. Correct. You shouldn't move a repository while Git operations are running in it. That would break for many reasons, not just because of this change to lockfile handling. 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