5 ms·

Made me curious, so I tried that exact prompt in the GPT-4 playground. Response: A wildcard in .gitignore file is a special character used to match multiple

Made me curious, so I tried that exact prompt in the GPT-4 playground. Response: A wildcard in .gitignore file is a special character used to match multiple file names or patterns. The most commonly used wildcards are: 1. `*`: This wildcard matches any number of characters in a single path component. For example, `*.txt` would ignore all files with a .txt extension. 2. `?`: This wildcard matches any one character in a single path component. For example, `file?.txt` would ignore files like "file1.txt" and "file2.txt" but not "file12.txt". 3. `**`: This wildcard is used to match any number of characters across multiple path components. For example, `**/build/` would ignore all files and folders named "build" at any level in the project structure. Examples: - `*.log`: Will ignore all files with a .log extension - `**/.DS_Store`: Will ignore all .DS_Store files in every folder - `build/`: Will ignore the "build" folder on top level directory - `/*/temp/`: Will ignore any "temp" folder at the second level of the directory structure (ignores sibling/temp, parent/child/temp but not sibling/child/temp) For more information, you can refer to the official git documentation on gitignore: https://git-scm.com/docs/gitignore

JoelEinbinder 3y ago
This is slightly wrong. build/ will ignore the build directory at every level. /build will ignore the build directory at the top level. I also have no idea what it’s trying to communicate with its /*/temp/ examples
- donmcronald 3y ago
  > This is slightly wrong. I wonder how it does if you tell it it’s wrong. I’ve tried a few times and it seems to get confused pretty easily.
  - pwdisswordfishc 3y ago
    "I apologize for the confusion. [Repeats the same wrong thing]"
- darknavi 3y ago
  > This is slightly wrong. A perfect representation of my git usage then!
- arp242 3y ago
  I once had a project with a "bin-name" in the gitignore, to exclude the "/bin-name" that "go build" will produce. Then I added a "dir/bin-name/file.go" which of course got excluded. The CI/CD builds failed, but it worked locally, and great confusion ensued. Since then, I've always added that leading "/" and generally try to be as specific as possible in gitignore files. This is a great example where many people providing different answers and comments based on their different knowledge and experience provide value, opposed to just ChatGPT telling you stuff. Simply "correct" is nice, but "correct, complete, and with experience and context" is better.
Tijdreiziger 3y ago
A priori, you can’t know whether this is accurate or a hallucination.
- ahahahahah 3y ago
  I really think the whole "hallucination" thing is a terrible framing. All that gpt-4 does is spew out bullshit. Now, it applies a bunch of statistics to attempt to spew out believable bullshit and those statistics cause it to sometimes accidentally be correct. The base assumption with this should be that it's wrong, and so we should instead be framing it as like sometimes accidentally producing "actualities" or something.

JoelEinbinder 3y ago

This is slightly wrong. build/ will ignore the build directory at every level. /build will ignore the build directory at the top level. I also have no idea what it’s trying to communicate with its /*/temp/ examples

donmcronald 3y ago
> This is slightly wrong. I wonder how it does if you tell it it’s wrong. I’ve tried a few times and it seems to get confused pretty easily.
- pwdisswordfishc 3y ago
  "I apologize for the confusion. [Repeats the same wrong thing]"
darknavi 3y ago
> This is slightly wrong. A perfect representation of my git usage then!
arp242 3y ago
I once had a project with a "bin-name" in the gitignore, to exclude the "/bin-name" that "go build" will produce. Then I added a "dir/bin-name/file.go" which of course got excluded. The CI/CD builds failed, but it worked locally, and great confusion ensued. Since then, I've always added that leading "/" and generally try to be as specific as possible in gitignore files. This is a great example where many people providing different answers and comments based on their different knowledge and experience provide value, opposed to just ChatGPT telling you stuff. Simply "correct" is nice, but "correct, complete, and with experience and context" is better.

Tijdreiziger 3y ago

A priori, you can’t know whether this is accurate or a hallucination.

ahahahahah 3y ago
I really think the whole "hallucination" thing is a terrible framing. All that gpt-4 does is spew out bullshit. Now, it applies a bunch of statistics to attempt to spew out believable bullshit and those statistics cause it to sometimes accidentally be correct. The base assumption with this should be that it's wrong, and so we should instead be framing it as like sometimes accidentally producing "actualities" or something.