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

Ignore ctags file #482

Merged
merged 1 commit into from
Mar 26, 2020
Merged

Ignore ctags file #482

merged 1 commit into from
Mar 26, 2020

Conversation

ChillerDragon
Copy link
Contributor

No description provided.

@codecov-io
Copy link

Codecov Report

Merging #482 into develop will not change coverage by %.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff            @@
##           develop     #482   +/-   ##
========================================
  Coverage    48.13%   48.13%           
========================================
  Files          128      128           
  Lines         9933     9933           
========================================
  Hits          4781     4781           
  Misses        5152     5152           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5e899bf...31c37de. Read the comment docs.

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 26, 2020

Since there's no ctags file in the repo, it doesn't really make sense to include an ignore rule for it.

As I only learned myself a few months ago, you can incorporate any additional local ignore rules you like (without throwing your branch out of sync with the repo) by adding them to .git/info/exclude.

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 26, 2020

Since there's no ctags file in the repo

Er, and the repo also doesn't normally generate a ctags file, to complete that thought.

The best uses for a checked-in .gitignore are:

  1. to protect checked-in files that get regenerated during development, but shouldn't be updated
  2. to exclude files commonly created during the development process, to avoid them getting accidentally checked in by people in the habit of doing blanket git adds.

(Though CMake's out-of-source builds are a huge help in preventing both of those in the first place, since it's one of the guiding principles of CMake that an impenetrable wall be maintained separating the source (input) dir from the build (output) dir.)

Still, a ctags file arguably falls under point 2, so it can't hurt. What the heck, merging.

@ferdnyc ferdnyc merged commit fda1357 into OpenShot:develop Mar 26, 2020
@ChillerDragon
Copy link
Contributor Author

When I do git commit it opens vim which then creates a tag file that then gets tracked the next time I do git add .

in the name of all ctags users thanks for merge <3

@ferdnyc
Copy link
Contributor

ferdnyc commented Mar 26, 2020

then gets tracked the next time I do git add .

Well, that's kind of what I was getting at with the blanket adds. I always try to talk people out of doing mass-adds, since that's how unrelated changes sneak into commits and PRs.

Targeted adds on individual files are best, so each commit comprises only intentional, explicitly-selected changes. But failing that (or at times when it's unrealistic), using git add -u (for --update) is preferable to a repo-wide git add ., since -u will ignore untracked files.

Or you can also just jump straight to git commit -a, which will have the same effect of adding all known files, but ignoring untracked ones.

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.

3 participants