It’s a good idea to have Clarion itself under version control, so you can check what was changed in the templates or classes when upgrading accessories or versions.
But Clarion has many directories with a combination of binary and text content, which makes it hard to choose what to add to the repository.
Here’s an alternate whitelist approach for configuring .gitignore, where you first exclude everything and then add just the directories or files you want.
## Setup
# Ignore all, allow directory traversal, keep .gitignore
*
!*/
!/.gitignore
## Include
# Include specific directories, anywhere (**/) or in the root folder (/)
!**/win/*
!/.vscode/*
# Include file extensions anywhere
!**/*.addin
!**/*.cmd
## Exclude
# Exclude folders and file extensions
/somefolder/
*.trf
*.zip
*.dctx
Just save it to your root Clarion folder (e.g.,C:\Clarion11.1), create a repository there and you can select all files in your first commit.
3 Likes
This worked great! Thank you!
Also, if you are going to commit the Clarion folder to git. Be sure to check into LFS (Large File Support) for the repo if you are committing DLLs and EXEs (or any binaries).
Searching the Git command to see a list of Ignored files Google AI returned:
git ls-files --others --ignored --exclude-standard
Explanation of the options:
--others: This option includes untracked files in the output.--ignored: This option includes ignored files in the output.--exclude-standard: This option makes Git apply the standard ignore rules, which include:
- Patterns in your
.gitignore file in each directory.
- Patterns in the
$GIT_DIR/info/exclude file.
- Patterns in the global excludes file specified by the
core.excludesFile configuration variable.
Alternatively, you can use git check-ignore to debug why specific files are ignored.
For instance, to see why a particular file is ignored, use the following command with the -v (verbose) flag:
git check-ignore -v path/to/your/file
This will show you which ignore rule and which .gitignore file is responsible for ignoring the specified file.
This requires careful planning ahead of time.
I was recently working in a repo that had some initially committed files of a certain type as non-LFS.
Subsequently, a rule was added to the .gitattributes to force that type of file to LFS.
Everything was fine for a very long time, until something caused git to have to re-read the info about those files. It causes a conflict that “normal” git actions can’t get around, so you have to do extra stuff (after trying everything you know 
)
I agree. I highly recommend setting up LFS when you first create the repo or you will have issues. If the repo already exists, I’d create a new one and move the files over from the old one.