[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21559: 25.0.50; auto-revert-mode breaks git rebase

From: Mitchel Humpherys
Subject: bug#21559: 25.0.50; auto-revert-mode breaks git rebase
Date: Sat, 06 Feb 2016 21:03:35 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (gnu/linux)

On Sat, Feb 06 2016 at 05:34:49 PM, Mitchel Humpherys <address@hidden> 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

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".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]