Currently, the documentation for the ignore key in GitRepository says:
// Ignore overrides the set of excluded patterns in the .sourceignore format
// (which is the same as .gitignore). If not provided, a default will be used,
// consult the documentation for your version to find out what those are.
// +optional
but it does not "override the set of excluded patterns", it "appends to the set of excluded patterns".
To illustrate, given the currently listed defaults (.git/, .gitignore, .gitmodules, .gitattributes) and a repository containing both .git/ and .gitignore, setting ignore: .git/ results in a tarball that is missing both .git/ and .gitignore. This wouldn't be override behavior because I'd have expected .gitignore (which is not in the overriden ignore key) to be in the tarball. However using ignore: !.gitignore results in a tarball that is missing .git/ and has .gitignore in it showing the append behavior.
I see two options to address this discrepancy
- Update the documentation to describe the append behavior
- Update the code to override instead of append
My personal preference is option 2 because it doesn't require a CR reader combine both what they can read as well as a piece of documentation they might not have close by in order to understand the outcome. That being said, I'm pretty ambivalent about which is chosen.
Currently, the documentation for the
ignorekey inGitRepositorysays:but it does not "override the set of excluded patterns", it "appends to the set of excluded patterns".
To illustrate, given the currently listed defaults (
.git/,.gitignore,.gitmodules,.gitattributes) and a repository containing both.git/and.gitignore, settingignore: .git/results in a tarball that is missing both.git/and.gitignore. This wouldn't be override behavior because I'd have expected.gitignore(which is not in the overridenignorekey) to be in the tarball. However usingignore: !.gitignoreresults in a tarball that is missing.git/and has.gitignorein it showing the append behavior.I see two options to address this discrepancy
My personal preference is option 2 because it doesn't require a CR reader combine both what they can read as well as a piece of documentation they might not have close by in order to understand the outcome. That being said, I'm pretty ambivalent about which is chosen.