Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta: Remove catchall lines in .gitignore #4565

Merged
merged 1 commit into from
Dec 27, 2020

Conversation

lanza
Copy link
Contributor

@lanza lanza commented Dec 27, 2020

These two lines caused this local .gitignore to supersede all inputs
in any files specified by a user's core.excludesFile configuration
since the first match was going to be !*.* for any file with a
decimal or any directory. git check-ignore -v somefile can be used to
test this.

These two lines caused this local .gitignore to supersede all inputs
in any files specified by a user's `core.excludesFile` configuration
since the first match was going to be `!*.*` for any file with a
decimal or any directory. `git check-ignore -v somefile` can be used to
test this.
@awesomekling
Copy link
Collaborator

All righty

@awesomekling awesomekling changed the title gitignore: Remove catchall lines Meta: Remove catchall lines in .gitignore Dec 27, 2020
@awesomekling awesomekling merged commit bee1774 into SerenityOS:master Dec 27, 2020
awesomekling added a commit that referenced this pull request Dec 27, 2020
This reverts commit bee1774.

It made our .gitignore ignore *everything*.
@awesomekling
Copy link
Collaborator

I reverted this in 45d1c08 since it caused us to gitignore everything
cc @linusg

bgianfo added a commit to bgianfo/serenity that referenced this pull request May 20, 2021
The wild card rules at the top of the .gitignore came from a time when
the build wrote back to the git repository and placed files right next
to the source. (Original commit that introduced them 37c27e2, they were
later consolidated into the root .gitignore in 802d4dc) We have since
moved to cmake, and these rules have become obsolete, and they just
cause issues where we need to go and add negations for these rules in
order for things to work.

A previous change attempted to remove the top wild card rules (PR SerenityOS#4565)
but it was later reverted, as they forgot to remove the top ignore
everything rule '*', so all files were ignored. This change just removes
all of these rules that no longer make sense, restoring a bit of sanity.

*.o,*.d,*.a rules were also from when the build wrote to the repository,
they are now defunct. The same goes for the *Endpoint.h and CMakeFiles
rules.

The lowercase build directory can be removed as we've standardized on
the uppercase 'Build' directory as the root of the build output dir.
awesomekling pushed a commit that referenced this pull request May 20, 2021
The wild card rules at the top of the .gitignore came from a time when
the build wrote back to the git repository and placed files right next
to the source. (Original commit that introduced them 37c27e2, they were
later consolidated into the root .gitignore in 802d4dc) We have since
moved to cmake, and these rules have become obsolete, and they just
cause issues where we need to go and add negations for these rules in
order for things to work.

A previous change attempted to remove the top wild card rules (PR #4565)
but it was later reverted, as they forgot to remove the top ignore
everything rule '*', so all files were ignored. This change just removes
all of these rules that no longer make sense, restoring a bit of sanity.

*.o,*.d,*.a rules were also from when the build wrote to the repository,
they are now defunct. The same goes for the *Endpoint.h and CMakeFiles
rules.

The lowercase build directory can be removed as we've standardized on
the uppercase 'Build' directory as the root of the build output dir.
Coderdreams pushed a commit to Coderdreams/serenity that referenced this pull request May 22, 2021
The wild card rules at the top of the .gitignore came from a time when
the build wrote back to the git repository and placed files right next
to the source. (Original commit that introduced them 37c27e2, they were
later consolidated into the root .gitignore in 802d4dc) We have since
moved to cmake, and these rules have become obsolete, and they just
cause issues where we need to go and add negations for these rules in
order for things to work.

A previous change attempted to remove the top wild card rules (PR SerenityOS#4565)
but it was later reverted, as they forgot to remove the top ignore
everything rule '*', so all files were ignored. This change just removes
all of these rules that no longer make sense, restoring a bit of sanity.

*.o,*.d,*.a rules were also from when the build wrote to the repository,
they are now defunct. The same goes for the *Endpoint.h and CMakeFiles
rules.

The lowercase build directory can be removed as we've standardized on
the uppercase 'Build' directory as the root of the build output dir.
Hendiadyoin1 pushed a commit to Hendiadyoin1/serenity that referenced this pull request May 24, 2021
The wild card rules at the top of the .gitignore came from a time when
the build wrote back to the git repository and placed files right next
to the source. (Original commit that introduced them 37c27e2, they were
later consolidated into the root .gitignore in 802d4dc) We have since
moved to cmake, and these rules have become obsolete, and they just
cause issues where we need to go and add negations for these rules in
order for things to work.

A previous change attempted to remove the top wild card rules (PR SerenityOS#4565)
but it was later reverted, as they forgot to remove the top ignore
everything rule '*', so all files were ignored. This change just removes
all of these rules that no longer make sense, restoring a bit of sanity.

*.o,*.d,*.a rules were also from when the build wrote to the repository,
they are now defunct. The same goes for the *Endpoint.h and CMakeFiles
rules.

The lowercase build directory can be removed as we've standardized on
the uppercase 'Build' directory as the root of the build output dir.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants