GNU bug report logs -
#21559
25.0.50; auto-revert-mode breaks git rebase
Previous Next
Reported by: Ben Gamari <ben <at> smart-cactus.org>
Date: Fri, 25 Sep 2015 14:31:02 UTC
Severity: normal
Found in version 25.0.50
Fixed in version 27.1
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On Sat, Feb 06 2016 at 05:34:49 PM, Mitchel Humpherys <mitch.special <at> gmail.com> wrote:
> I took a quick look at the git source and the main source of this
> particular error seems to be from the `git update-index' command. I see
> that vc-git.el is calling `git update-index' in a few places but my
> attempts at instrumenting the code to track down where it was coming
> from were fruitless. I tried:
>
> (setq vc-command-messages t)
>
> as well as:
>
> (defun vc-git-command (buffer okstatus file-or-list &rest flags)
> "A wrapper around `vc-do-command' for use in vc-git.el.
> The difference to vc-do-command is that this function always invokes
> `vc-git-program'."
> (let ((coding-system-for-read vc-git-commits-coding-system)
> (coding-system-for-write vc-git-commits-coding-system))
> + (message "git: %s %s" file-or-list flags)
>
> Any ideas on how we can trace every git command that vc-git.el is
> running? I'm suspicious that we're calling `git update-index' in the
> auto revert path somewhere...
Sorry, I take it all back. `git update-index' is the source of that one
particular index.lock error message, but it's certainly not the only
thing holding index.lock... And actually it looks like `git ls-files'
does take index.lock:
$ cd /path/to/emacs/
$ git ls-files # in another shell after running the following inotifywait:
$ inotifywait -m .git | grep index.lock
Setting up watches.
Watches established.
.git/ CREATE index.lock
.git/ OPEN index.lock
.git/ CLOSE_WRITE,CLOSE index.lock
.git/ DELETE index.lock
.git/ CREATE index.lock
.git/ OPEN index.lock
.git/ CLOSE_WRITE,CLOSE index.lock
.git/ DELETE index.lock
I did a bit of git debugging and it looks like someone must be
registering an atexit handler or something that takes index.lock,
because it doesn't get taken in the ls-files code itself. It's taken
sometime after the `exit' function gets called in `handle_builtin' in
git.c.
Anyways, I'm more inclined now to agree that this a git bug. I don't
see why `git ls-files' would be taking index.lock... So we're back to
the question of "how can Emacs handle this more gracefully".
This bug report was last modified 6 years and 294 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.