[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:21:34 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (gnu/linux) |
On Sat, Feb 06 2016 at 09:03:35 PM, Mitchel Humpherys <mitch.special@gmail.com>
wrote:
> On Sat, Feb 06 2016 at 05:34:49 PM, Mitchel Humpherys
> <mitch.special@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".
SORRY! I take it all back AGAIN. It was actually my shell's PS1 that
was locking index.lock (due to a `git status'), not `git ls-files'!
That's why it looked like it was happening when the program exited.
Because it really was after the program exited :). That's
embarassing...
After re-running my experiment above in a non-fancy shell I don't see
index.lock being taken at all when I run `git ls-files'.
So we're back to instrumenting vc{,-git}.el to see exactly which git
commands are being run when auto-revert refreshes a buffer.
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase, Mitchel Humpherys, 2016/02/05
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase, Ben Gamari, 2016/02/06
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase, Mitchel Humpherys, 2016/02/06
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase, Mitchel Humpherys, 2016/02/07
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase,
Mitchel Humpherys <=
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase, Ben Gamari, 2016/02/07
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase, Ben Gamari, 2016/02/07
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase, Mitchel Humpherys, 2016/02/07
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase, Ben Gamari, 2016/02/07
- bug#21559: 25.0.50; auto-revert-mode breaks git rebase, Daniel Colascione, 2016/02/08