> On 11 Feb 2022, at 14:50, Kristof Provost <k...@freebsd.org> wrote:
>
> On 11 Feb 2022, at 15:38, Drew Gallatin wrote:
>
> The problem seems to be that all of these solutions are processed *FIRST*,
> before a .gitignore in the repo, so they cannot be used to negate a
> gitignore rule in the repo. Eg:
>
>
> The man page claims this:
>
> When deciding whether
> to ignore a path, Git normally checks gitignore patterns from multiple
> sources, with the following order of precedence, from highest to lowest
> (within one level of precedence, the last matching pattern decides the
> outcome):
>
> And then lists command line, .gitignore file in the same directory as the
> path, or in any parent directory, GIT_DIR/info/exclude and core.excludesFile.
>
> So it’s does check them in the order you’d expect, but apparently does not
> let GIT_DIR/info/exclude overrule .gitignore. That’s a bit unfortunate. I’d
> really have expected a ‘!*.orig’ in GIT_DIR/info/exclude to overrule the
> .gitignore, but I’ve also tested it and it doesn’t.
>
> This makes a stronger case that those who want to ignore .orig and .rej
> files can add them to *their* local .gitignore, and we should back them out
> of the .gitignore for the project.
>
>
I don’t have a _strong_ opinion on keeping .orig/.rej. Again, .gitignore is for
people's convenience. Given there’s no good way for overriding these with local
configuration - probably it’s better to not have the in our repo indeed.
I raised https://reviews.freebsd.org/D34254 & added Andrew&all original
reviewers there.
> I don’t really like it (for the usual reasons: .orig & friends should pretty
> much never get checked in, so .gitignore is appropriate. Your workflow is a
> bit unusual, so ideally you’d do the special thing.), but yeah, it looks like
> we should indeed remove them from .gitignore in the repo.
>
> Kristof
>
