[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1589: 23.0.60; vc-dir erroneously reports "No changes between workin
From: |
Dan Nicolaescu |
Subject: |
bug#1589: 23.0.60; vc-dir erroneously reports "No changes between working revision and workfile" |
Date: |
Wed, 17 Dec 2008 13:14:18 -0800 (PST) |
Eric Hanchrow <eric.hanchrow@gmail.com> writes:
> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.
>
> Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing
list.
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> Edit the third line of this script to point to your Emacs, and then run it.
>
> #!/bin/sh -x
>
> EMACS=/usr/local/src/emacs-with-my-tweaks.git/src/emacs
>
> cd /tmp
> rm -rf xyzzy
>
> mkdir xyzzy
> cd xyzzy
> git init
> mkdir Jack Jill
> touch Jack/it Jill/it
> git add .
> git commit -m "golly!"
> echo More stuff >> Jack/it
> cd Jill
>
> git status
> # You should see this output:
>
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working
directory)
> #
> # modified: ../Jack/it
> #
>
> $EMACS -Q \
> --eval '(cd "/tmp/xyzzy/Jill")' \
> --eval '(vc-dir "/tmp/xyzzy/Jill")'
>
> # note that we're now looking at something like
>
> # VC backend : Git
> # Working dir: /tmp/xyzzy/Jill/
> # Branch : master
> #
> # ./
> # Jack/
> # edited Jack/it
> #
> #
This is not a vc-dir problem, but a vc-git.el problem. vc-dir just
displays whatever vc-git-dir-status returns. In this case
vc-git-dir-status should not return anything about "Jack".
> # That seems a bit odd, since the name "Jack/it" doesn't name anything
> # at all when interpreted relative to /tmp/xyzzy/Jill.
>
> # Furthermore, if you move point to "Jack/it" (by typing "n" twice),
> # and then invoke vc-diff by typing "=", Emacs will respond with "No
> # changes between working revision and workfile", which is wrong; the
> # file is indeed modified.
I'm guessing this is just an artifact because of the previous
problem...