status: invalidate dirstate on LockError If we cannot take the lock, someone else is modifying the repository. Let us discard dirstate uncommitted data before exiting the status code. Having a clean dirstate after such operation seems safer. Strictly speaking, there is a small behavior change in the following situation: * process A call `status` outside of the `wlock` * process B grab the `wlock` * process A fails to acquires the lock to write status fixup * process B release the `wlock` *without touching the dirstate* * process A later grab the `wlock` * process A can write dirstate update from earlier `status` However this is a fairly hypothetical situation : * process A has to be raced * process B have to not update the dirstate * process A has to run another *unrelated* operation later. This seems rare enough to overlook. I am stating that the two operations in process A has to be unrelated. Otherwise, collecting status data outside of the lock to use them inside the lock is racy. Any other process could move things around (eg: the working copy) making the data collected during status irrelevantor even harmful. If such code exists, it should be fixed ASAP.