0

As shown in the picture, the git add * command does not track a .sh file whose name does not start with a dot. But if I specify the file in the git add command, it can track it. I wonder why this happens?

enter image description here

This post explains the differences between git add *, git add ., etc, but it doesn't explain my problem.

Michael Chao
  • 570
  • 5
  • 14
  • 3
    When you're asking for help, you’ll get more/better answers if you don’t post screenshots or photos. Cut & paste the text directly into the message. Why? 1. It's easier for people to read it. 2. It allows those reading it to cut & paste the text, making it easier to work on solving your problem. 3. It makes it searchable, so that someone can find this thread when Googling for information in the future. 4. A screen reader can't read a picture which limits access to some in our community. – Andy Lester May 09 '22 at 14:32
  • @0stone0 Not really. According to that post, I shouldn't meet this problem. – Michael Chao May 09 '22 at 14:35
  • 2
    As explained at https://stackoverflow.com/questions/26042390/git-add-asterisk-vs-git-add-period, the wildcard is handled by the shell rather than git. Removed files aren't there any more. Try `echo *` to get an idea of what git sees. – Álvaro González May 09 '22 at 14:35
  • @ÁlvaroGonzález Could you give more explanation? Why `git add *` cannot track it, but `git status` and `git add ` can? Also, does this apply to all deleted files? I believe previously all my deleted files are tracked by git. – Michael Chao May 09 '22 at 14:39
  • 2
    This is not just about `git`. For _any_ time when you start a UNIX program from a POSIX-compliant shell, `*` is replaced with a list of filenames that actually exist on the filesystem _before the program starts_, so the program has no way of knowing there was originally a `*` there at all. – Charles Duffy May 09 '22 at 14:58
  • 1
    The [second answer to the linked question](https://stackoverflow.com/a/26042516/1256452) mentions this feature of shells. Note, however, that if you're using the `CMD.EXE` "DOS-style" CLI, that CLI *does not* expand `*` and passes the literal character `*` to Git; Git itself will then do *its own* expansion, which will achieve what you intended here! So it is CLI-dependent. – torek May 09 '22 at 15:24

1 Answers1

4

What you want to do is git add --all.

The reason for git add * not working is that the shell will expand the * argument to a list of all the names of the files/folders in the current directory.

But because commit.sh does not exist, your shell with not see it.
Therefore deleted files will not be passed as arguments to git add when using the shell's * expansion.

Jay
  • 3,640
  • 12
  • 17
  • Does this apply to all file types? I believe previously when I deleted files, `git add *` can track them all. – Michael Chao May 09 '22 at 14:48
  • 2
    Yes, it applies to all file types. Maybe it worked for you in the past with files in *subfolders*. Because there the problem does not exist (folder name gets passed to `git add` and it will notice the missing file inside) – Jay May 09 '22 at 14:50
  • @Jay, thanks jay, learned something new today. – Dante1021 May 09 '22 at 15:01
  • 2
    @Madhan1021 Yourte welcome, thanks for asking :) By the way, if you ever run into confusion when using `*`, just add `echo ` at the beginning to see what the actually executed command looks like after shell expansion; e.g. `echo git add *` – Jay May 09 '22 at 15:07