GNU bug report logs - #21559
25.0.50; auto-revert-mode breaks git rebase

Previous Next

Full log

View this message in rfc822 format

From: Ben Gamari <ben <at> smart-cactus.org>
To: Mitchel Humpherys <mitch.special <at> gmail.com>
Cc: 21559 <at> debbugs.gnu.org
Subject: bug#21559: 25.0.50; auto-revert-mode breaks git rebase
Date: Sat, 06 Feb 2016 13:34:06 +0100

[Message part 1 (text/plain, inline)]

Mitchel Humpherys <mitch.special <at> gmail.com> writes:

> On Fri, Sep 25 2015 at 03:45:56 PM, Ben Gamari <ben <at> smart-cactus.org> wrote:
>> Arguably `git rebase` should be holding the `index.lock` for the entire
>> duration of the process (or be more resilient to the lock being taken)
>> but sadly this isn't the case. Emacs should behave appropriately to
>> accomodate this behavior.
>
> I don't think this is quite right.  As I understand it, git only takes
> index.lock for operations that mutate the index [1].
>
> It wouldn't make sense for git to hold index.lock for the entirety of
> the rebase operation since you can stop in the middle of an interactive
> rebase and do anything you want (mess with the index, add new commits,
> anything).
>
Ahh, yes. You are quite right.

> I think the real question is: why is vc-find-file-hook (or
> vc-refresh-state) trying to mutate the index?  Shouldn't refreshing a
> buffer be a read-only operation (at least with respect to the VCS)?
>
As far as I can tell vc-find-file-hook is merely calling `git ls-files
-c -z -- $FILE`, which sounds to me like it should indeed be a read-only
operation.

Cheers,

- Ben

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.