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

From: Ben Gamari <[email-masked]>
Date: Sun, 07 Feb 2016 11:22:08 +0100

Mitchel Humpherys <[email-masked]> writes:

> So we're back to instrumenting vc{,-git}.el to see exactly which git
> commands are being run when auto-revert refreshes a buffer.

I recently revisited this and came up with this hack (after realizing
that my previous tracing approach was badly broken),

    (defun my-tracing-function (orig &rest args)
      (message "call-process %s" args))
    (advice-add 'call-process :before #'my-tracing-function)
    (message "installed")

This produces,

    call-process (nil (t nil) nil ls-files -c -z -- COPYING)
    call-process (nil (t nil) nil rev-parse HEAD)
    call-process (nil (t nil) nil symbolic-ref HEAD)
    call-process (nil (t nil) nil diff-index -p --raw -z HEAD -- COPYING)
    call-process (nil (t nil) nil status --porcelain -- COPYING)
    call-process (nil (t nil) nil ls-files -c -z -- COPYING)
    call-process (nil (t nil) nil rev-parse HEAD)
    call-process (nil (t nil) nil symbolic-ref HEAD)
    call-process (nil (t nil) nil diff-index -p --raw -z HEAD -- COPYING)
    call-process (nil (t nil) nil status --porcelain -- COPYING)
    Quit
    call-process (nil (t nil) nil ls-files -c -z -- COPYING)

After stracing each of these I've found that status --porcelain indeed
takes index.lock. Unfortunately I can't find a good explanation of why
this is necessary.