Re:

[Trying with another e-mail address for Martin Nicolay. Maybe the one
from the in-body From header works better. wsmn.osm-gmbh.de couldn't be
found.]

On Fri, 15 Nov 2019 at 17:29, Martin Ågren [off-list ref] wrote:

Hi Martin

On Fri, 15 Nov 2019 at 17:17, Martin Nicolay [off-list ref] wrote:

quoted

While working with complex scripts invoking git multiple times my
editor detects the changes and calls "git status". This leads to
aborts in "git-stash". With this patch and an appropriate value
core.fileslocktimeout this problem goes away.

Are you able to patch your editor to call
  git --no-optional-locks status
instead? See the bottom of git-status(1) ("BACKGROUND REFRESH") for more
on this.

quoted

+long get_files_lock_timeout_ms(void)
+{
+       static int configured = 0;
+
+       /* The default timeout is 100 ms: */
+       static int timeout_ms = 100;
+
+       if (!configured) {
+               git_config_get_int("core.fileslocktimeout", &timeout_ms);
+               configured = 1;
+       }
+
+       return timeout_ms;
+}
+

quoted

@@ -172,7 +174,7 @@ static inline int hold_lock_file_for_update(
                struct lock_file *lk, const char *path,
                int flags)
 {
-       return hold_lock_file_for_update_timeout(lk, path, flags, 0);
+       return hold_lock_file_for_update_timeout(lk, path, flags, get_files_lock_timeout_ms() );
 }

This looks like it changes the default from 0 ("try exactly once") to
100ms. Maybe we should stick with 0 for those who don't jump onto this
new config knob?

Martin