{"thread":{"id":"40932","subject":"Feature request - allow requesting a lock timeout","startedAt":"2015-12-04T14:28:27Z","lastAt":"2015-12-04T14:28:27Z","messageCount":1,"participants":["Nathan Neulinger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"274000","messageId":"5661A30B.6030803@neulinger.org","threadId":"40932","inReplyTo":null,"subject":"Feature request - allow requesting a lock timeout","fromName":"Nathan Neulinger","fromEmail":"nneul@neulinger.org","sentAt":"2015-12-04T14:28:27Z","receivedAt":"2015-12-04T14:28:27Z","isPatch":false,"sender":{"key":"nneul@neulinger.org","avatar":"https://gravatar.com/avatar/6bf7d938addba77b29fe46572be573fd52d1e4dbea47218c4397d760c87aabd1?d=mp&s=160"},"body":"It appears that almost all of the locking calls in the current code use hold_lock_file_for_update() which translates \ninto a request with zero timeout.\n\nThis effectively means that for certain classes of usage, you can't use git concurrently without either external locking \nor retry logic. It would be nice to see a global option \"--lock-timeout\" that would request a specific non-zero default \ntimeout for many of those operations.\n\nEven having the option to have a couple-second timeout would eliminate most typical concurrency issues, simplifying some \nautomated use cases.\n\nHorrible/contrived example, but demonstrates the issue:\n\n\tfor f in `seq 1 150`; do touch $f; (git add $f &); done\n\nYou'll get a whole bunch of:\n\n\tfatal: Unable to create '/tmp/dummy/.git/index.lock': File exists.\n\n-- Nathan\n\n------------------------------------------------------------\nNathan Neulinger                       nneul@neulinger.org\nNeulinger Consulting                   (573) 612-1412\n"}]}