* Bug Report: git ls-files -d
@ 2021-09-27 13:36 Calvin Taylor
2021-09-27 21:21 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: Calvin Taylor @ 2021-09-27 13:36 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 32 bytes --]
--
Calvin Taylor
506 260-2866
[-- Attachment #2: git-bugreport-2021-09-27-0939.txt --]
[-- Type: text/plain, Size: 2001 bytes --]
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
have macos and I have some commands possibly remapped like gsed, gfind to sed, find
What did you expect to happen? (Expected behavior)
git ls-files -d to show deleted files in my repository
What happened instead? (Actual behavior)
nothing is shown, I enabled GIT_TRACE=1, and started bash incase oh-my-zsh might have been interfereing, and got similar results
$ git ls-files -d
09:42:47.692880 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Library/Developer/CommandLineTools/usr/bin/git
09:42:47.693591 exec-cmd.c:238 trace: resolved executable dir: /Library/Developer/CommandLineTools/usr/bin
09:42:47.695053 git.c:444 trace: built-in: git ls-files -d
09:42:47.764089 exec-cmd.c:139 trace: resolved executable path from Darwin stack: /Library/Developer/CommandLineTools/usr/bin/git
09:42:47.764921 exec-cmd.c:238 trace: resolved executable dir: /Library/Developer/CommandLineTools/usr/bin
09:42:47.765919 git.c:444 trace: built-in: git config --get oh-my-zsh.hide-dirty
What's different between what you expected and what actually happened?
I have several directories I'd like to delete temporarily so I can simplify and study build processes
Anything else you want to add:
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.30.1 (Apple Git-130)
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64
compiler info: clang: 12.0.5 (clang-1205.0.22.6)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Bug Report: git ls-files -d
2021-09-27 13:36 Bug Report: git ls-files -d Calvin Taylor
@ 2021-09-27 21:21 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2021-09-27 21:21 UTC (permalink / raw)
To: Calvin Taylor; +Cc: git
What did you expect to happen? (Expected behavior)
git ls-files -d to show deleted files in my repository
What happened instead? (Actual behavior)
nothing is shown
Does not reproduce to me.
$ git reset --hard
$ git ls-files -s COPYING
100644 536e55524db72bd2acf175208aef4f3dfc148d42 0 COPYING
$ ls -1 COPYING
COPYING
$ git ls-files -d; echo no output
no output
$ rm COPYING
$ git ls-files -d
COPYING
Did you remove any file? "ls-files -d" reports the working tree
files that have been removed that are still known by the index.
So, after all of the above
$ git rm --cached COPYING
$ git ls-files -d; echo no output
no output
is perfectly expected.
Unlike "git ls-files" that checks the working files against what is in
the index, "git status" checks them against both the index and the
HEAD, so after all of the above, it would notice the removal
relative to HEAD:
$ git status -uno --porcelain
D COPYING
HTH.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-09-27 21:21 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-27 13:36 Bug Report: git ls-files -d Calvin Taylor
2021-09-27 21:21 ` Junio C Hamano
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.