Gitignore for media directory

[addison74]

I recently created PR #2269 that is merged into the code. It aimed to remove all other .gitignore files and use from now on only the one in root for better control. I proposed a modification for the /media directory based on a template provided by GitHub when you create a new repository:

/media/*
!/media/.htaccess
!/media/custom_options/.htaccess
!/media/customer/.htaccess
!/media/dhl/logo.jpg
!/media/downloadable/.htaccess

By reading more Internet resources about .gitignore content like these two:

https://www.golinuxcloud.com/gitignore-examples/

https://linuxize.com/post/gitignore-ignoring-files-in-git/

https://riptutorial.com/git/example/885/ignoring-files-and-directories-with-a--gitignore-file

I came to the conclusion that the approach wouldn't be correct at all.

Here is what is said in the articles "If a directory is marked to be ignored then any files or directories inside this directory will also be ignored by default. Using negate (!) pattern will also not be able to exclude files or directories from these excluded directory."

On the current version I modified the /media/.htaccess file and git immediately recognized the modification. I will do more simulations before drawing a final conclusion. I was convinced that the negation after a directory has an effect, but it seems not.

Here is another article
https://www.atlassian.com/git/tutorials/saving-changes/gitignore.

Pattern

logs/
!logs/important.log

Matches

logs/debug.log
logs/important.log

Explanation

"Wait a minute! Shouldn't logs/important.log be negated in the example on the left

Nope! Due to a performance-related quirk in Git, you can not negate a file that is ignored due to a pattern matching a directory"

[addison74]

There is a big difference between

/log/
!/log/important.log

and

/log/*
!/log/important.log

In the first case, git does not detect the changes in the important.log file, but in the second case, it does. The observation in the articles is correct, but only for the first implementation.

My personal conclusion is that the version we use now in OpenMage is correct and does not require changes.