Thread (3 messages) flat view 3 messages, 2 authors, 2019-11-15
  • (no subject) · Martin Nicolay <hidden> · 2019-11-15
  • Re: · Martin Ågren <hidden> · 2019-11-15
  • Re: · Martin Ågren <hidden> · 2019-11-15

Re:

From: Martin Ågren <hidden>
Date: 2019-11-15 16:29:51

Hi Martin

On Fri, 15 Nov 2019 at 17:17, Martin Nicolay [off-list ref] wrote:
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.
+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 hunk ↗ jump to hunk
@@ -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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help