I have accidentally committed a core file once
(https://github.com/llvm/llvm-project/commit/af73834243a1035787935960bfd5a71713b89701)
due to not paying close enough attention to commit diffs and my CWD.
This patch adds rule in .gitignore to ignore core files so that the same
mistake is less likely to happen again.`
Details
Details
- Reviewers
MaskRay JDevlieghere
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| .gitignore | ||
|---|---|---|
| 26 | Should this be just core (i.e. without the *)? At least on Linux core is the default core file name, right? An on macOS they're off by default and end up under /cores anyway. We have a few core files checked in as part of the LLDB test suite but they usually have a descriptive name, such as subject.core that would get matched with the current pattern. | |
Comment Actions
IMHO .gitignore is for files that are strictly project-related. Everything else should go into local .git/info/exclude.
I have accidentally committed a core file once
You might as well have committed any arbitrary file, e.g. 1.txt. This does not mean '*.txt' should end up in .gitignore.
It is the committers responsibility to check that everything is OK, and there is also a review process.
Comment Actions
For the most part, I agree. However, there are already some artifacts that might not be classified as strictly project related that are in the .gitignore. We have exceptions for things like artifacts produced by IDEs (VSCode, VS), tools like clangd, vim swap files, etc. I think it's sort of an arbitrary boundary on what we consider project related and what we don't. I thought this would be something reasonable to add, but I'm happy to hear feedback from the community and augment/abandon these if the consensus is against this.
You might as well have committed any arbitrary file, e.g. 1.txt. This does not mean '*.txt' should end up in .gitignore.
It is the committers responsibility to check that everything is OK, and there is also a review process.
Right, it could've been any arbitrary file. I have been making sure to check my commits more carefully as well. However, I think core files are slightly different. With Linux development, I think there's a reasonable expectation they'll pop up at some point in places they're not supposed to, they're large in size which impacts repository size when they end up in tree, and if there's just a file named core, it's almost certainly a core dump and not meant to end up in tree. I also don't think there's a large cost to adding it to the .gitignore as long as it doesn't create any off-target effects.
| .gitignore | ||
|---|---|---|
| 26 | Good point. The default file name on Linux is just core. My original thinking was that this would still catch things if the default file name is modified (ie if a timestamp/PID/executable name gets appended which I think is a reasonably common configuration), but this definitely does increase the chance for offtarget effects. I've changed it to match a file called core in any directory. I checked with git check-ignore across the whole monorepo and there were no off-target matches, and I think this should be reasonable, but I'd like your thoughts on this (e.g., if we want to restrict it further, maybe even to just the root directory). | |
Comment Actions
I agree. core looks too special to ignore in the global configuration file.
I have accidentally committed a core file once
You might as well have committed any arbitrary file, e.g. 1.txt. This does not mean '*.txt' should end up in .gitignore.
It is the committers responsibility to check that everything is OK, and there is also a review process.
Comment Actions
I'll abandon this patch now based on feedback. Thank you everyone for the responses and your time in explaining the costs to such a change that I didn't realize. Sorry for taking up your time.
Should this be just core (i.e. without the *)? At least on Linux core is the default core file name, right? An on macOS they're off by default and end up under /cores anyway.
We have a few core files checked in as part of the LLDB test suite but they usually have a descriptive name, such as subject.core that would get matched with the current pattern.