In the documentation of pythonforandroid, at https://python-for-android.readthedocs.io/en/latest/buildoptions/, there is a build option described called blacklist.
--blacklist: The path to a file containing blacklisted patterns that will be excluded from the final APK. Defaults to ./blacklist.txt
However, not a word can be found anywhere about how to use this file and what exactly the patterns are supposed to represent. For instance, is this used to exclude libraries, files, or directories? Do the patterns match file names or contents? What is the syntax of the patterns, or an example of a valid blacklist.txt file?
This file should contain a list of glob patterns, i.e. as implemented by fnmatch, one per line. These patterns are compared against the full filepath of each file in your source dir, probably using a global filepath but I'm not certain about that (it might be relative to the source dir).
For instance, the file could contain the following lines:
*.txt
*/test.jpg
This would prevent all files ending with .txt from being included in the apk, and all files named test.jpg in any subfolder.
If using buildozer, the android.blacklist_src buildozer.spec option can be used to point to your choice of blacklist file.
I have mutiple folders I want to include in doxywizard. Any Idea how can I do that? Currently If I select folder with multiple subfolder in it and when I run doxygen, It is not showing me any output.
When having specified just folders in the INPUT tag the files here are handled but not the files in subdirectories. For the later ones one needs the RECURSIVE tag (from the documentation):
RECURSIVE
The RECURSIVE tag can be used to specify whether or not subdirectories should be searched for input files as well.
The default value is: NO.
According to docs conditional truthy could also be used include/exclude files or directories . how can I do it in practice ? if I add all the files and directories to the template, how can I exclude them from the project based on the condition ?
* According to this issue, it is not possible but according to the docs (IIUC) it should work. This is pretty confusing
If you don't want to include some files, you should set its name to be something like $if(some_condition.truthy)$your_file_name.scala$endif$
When some_condition is false, this file won't be created.
There are some examples in http4s.g8. In directory src/main/g8/, there is a file called $if(graal_native_image.truthy)$native-image-readme.md$endif$. If the variable graal_native_image is set to true, a file named native-image-readme.md will be created. Otherwise, this file won't be created.
This method is also worked for directories, as long as you use the same pattern for the directory name.
I am using Eclipse (this is probably irrelevant) and I want to exclude Maven target folder from commit.
There are lots of notations
/target/**
*/target/*
/target/**
target/
/target/
What is the difference?
And what is the exact meaning of each of them?
TL;DR: you probably want /target/.
Long
Let's start with a clear definition of the work-tree (from the gitglossary, where it is spelled working tree):
The tree of actual checked out files. The working tree normally contains the contents of the HEAD commit’s tree, plus any local changes that you have made but not yet committed.
We need to keep in mind that what Git stores, and exchanges with other Git repositories, are commits. Each commit freezes, for all time, some set of files so that at any time in the future, you can tell Git get me commit a123456... and get all your files back as of the time you made commit a123456.... (Each commit has a unique, big-and-ugly hash ID like this, which you'll see in git log output and elsewhere.)
Commits vs the work tree
The files inside commits are stored in a special, Git-only, compressed, de-duplicated, and read-only form. I like to call these files freeze-dried. They literally cannot be changed. So they're fine for archival, but completely useless for getting any actual work done. Git therefore needs to be able to extract any given commit, "rehydrating" the freeze-dried files and turning them back into ordinary everyday files that you can see and use and work with. The place you put these files is the work-tree or working tree.
The working tree of course has a top level directory (or folder if you prefer that term), in which you store various files, including your main .gitignore file. That top level directory can have sub-directories (sub-folders) and each sub-folder can have its own .gitignore file too. This is important when you ask about /target vs target, for instance.
Gitignore entries
An entry in a .gitignore file can be in any of the following forms:
name (with no special characters like *)
name.* or *.txt or even name*txt
folder/
folder/*
folder/name
folder/name*txt or any of these variants
folder/subfolder/
folder/subfolder/*
any of the above prefixed with a slash, e.g., /name or /folder/ or /folder/name
any of the above, including prefixed-with-slash, that are then also prefixed with !, e.g., !/folder/name
This is not meant to be an exhaustive list (you have listed several other forms), but rather to illustrate a few basic principles:
A simple file name means any file or directory with this name.
A name suffixed with a slash means any directory (folder) with this name. Entities that are files don't match this kind of entry.
Entries can have embedded slashes—slashes that are not at the front, and not at the rear, such as folder/name.
Entries can have leading slashes, such as /name or /folder/, or both leading slashes and embedded slashes, such as /folder/name.
Entries can have glob characters, * and **, in various places.
Entries can be prefixed with !.
The rules for gitignore entries get pretty complicated, but start out simple enough. Remember that the .gitignore could be in the top level folder of your work-tree, or in some sub-folder!
A plain name, with no embedded or leading slashes, matches any file or folder anywhere from this folder or any of its sub-folders.
A slash-suffixed name, with no embedded or leading slashes, matches any folder (but not file) from this folder or any of its sub-folders.
If an entry has a slash prefix or an embedded slash—either one suffices—the entry matches only files and/or folders in this folder. Hence folder/name and /folder/name mean the same thing: match a file (or folder) named folder/name in this folder—i.e., the place containing the .gitignore file. Do not match the file sub/folder/name, for instance.
If an entry ends with a trailing slash, it only matches folders (regardless of anything else).
You said:
I want to exclude Maven target folder
This requires answering a sub-question: Where does this Maven target folder exist? Is there only one such folder, or can there be target/ entities in sub-folders? (There's also a separate issue, which is that .gitignore directives don't mean quite what people think they mean, and that you need to pay attention to what's in your index, but we'll leave that for another section.)
If this means: Don't include anything in target at the top level of my work-tree, but do go ahead and include, e.g., files named sub/target/file then you should use:
/target/
as the full rule in the .gitignore in the top level of your work-tree. It's slightly redundant since you already know that /target is a folder, but it expresses clearly that you want to ignore the folder named target in the top level of your work-tree.
If this means: Don't include anything in build-artifacts/target/, then you can put:
build-artifacts/target/
or:
/build-artifacts/target/
into the top-level .gitignore; or you can put:
/target/
into build-artifacts/.gitignore. The one in build-artifacts/.gitignore needs a leading slash because /target/ has no embedded slash, while the one in the top level .gitignore does not require a leading slash because it has an embedded slash.
If, on the third hand (first foot?), the requirement is to ignore all files in any folder whose folder-path contains a target component—e.g., you not only want to ignore target/file but also sub/target/file2 and sub/target/sub2/file3—then you should use:
target/
as your .gitignore entry, probably at the top level of your work-tree.
The role of the index / staging-area
The .gitignore files are about things in your work-tree, but Git does not build new commits from your work-tree. Instead, Git builds new commits from an intermediate thing that it calls, variously, the index or the staging area. (These two terms refer to the same entity.)
While the index has some other roles, its main one, especially for our purposes here, is that it holds a copy of every file from the original commit you extracted, or an updated copy or a totally new file. That is, if you extracted a commit that had just the two files files file1 and folder/file2, your index would now have copies of file1 and folder/file2 in it.
The copies inside the index are in the same freeze-dried format as the copies inside a commit. The difference is that you can replace the copies in the index—or add to them, or even subtract them away. That is, you can run git add file1 to take the useful version of file1 in your work-tree, freeze-dry it, and stuff that into the index. You can do the same with folder/file2, and you can put new files like folder2/file3 or ./file4 too. What git add does, in short, is to freeze-dry the work-tree version of the file and stuff it into the index.
When you run git commit, Git simply packages up everything that's in the index right then and make the new commit from that. So that's why you have to git add files all the time: every time you change the work-tree copy, you need to update the index copy, otherwise Git won't save the new version: Git will just re-save the old version again. (To save space, commits that save the same version of an old file really just re-use the old freeze-dried file. They can do that because these files are read-only. It's always safe to locate an old copy and re-use it, because by definition, everything inside Git is frozen for all time. Only the index and work-tree copies can be changed!)
In other words, you can think of the index as the proposed next commit. You copy files into it to update the proposed next commit. To remove a file entirely from the proposed next commit, you use git rm --cached or git rm (without --cached): Git will remove the file from the index, and maybe from the work-tree too, and now your proposed next commit just doesn't have the file at all.
A file can be in the index / staging-area and in the work-tree. That happens all the time. Such a file is called tracked. The contents don't have to match: it's just the fact that the file is in the index right now, and also in the work-tree, that makes the work-tree file tracked.
If a file is tracked—if it's in the index right now—then nothing you do with a .gitignore will affect it at all. To make it not tracked, you have to remove it from the index.
If you remove the file from the index—or if it's already not in the index now because it wasn't in the commit you checked out earlier—then the work-tree copy is untracked. Now the .gitignore entry matters. The .gitignore entry tells Git:
Don't complain about this file. Normally, git status would whine at you, telling you that the file is untracked and, gosh golly gee, shouldn't you git add it? The .gitignore makes Git shut up about that file.
Don't automatically add this file. If you use git add . or git add * or something like that, you're telling Git: add everything. The .gitignore modifies this to be: add everything—except these untracked files that are also ignored, don't add those!
It has a third effect, which is to give Git permission to clobber the work-tree file in some (rare-ish) cases, and to change the way git clean works with -x and -X.
Really, the file should not be called .gitignore, but rather something like .git-dont-whine-about-these-files-and-do-not-auto-add-them-either-and-maybe-occasionally-do-clobber-or-clean-them. But who wants to type that in all the time? So, .gitignore.
Conclusion
There is even more to know about .gitignore entries, but this is already long enough (maybe too long). The summary version is:
.gitignore only affects untracked files;
it's mainly about shutting up whining, and avoiding auto-adding; and
use a trailing slash to mean directory / folder (whichever word you prefer) and a leading slash to mean as found in this directory. When you have complex entries (with embedded slashes), the leading slash is redundant, but conveys your intent.
If you don't want the leading-slash effect, but do need embedded slashes, you either have to distribute your ignore entries to sub-directories / sub-folders, or use the ** notation (as a leading component) to match any number of path components. Otherwise there's rarely any need for ** at all.
Not covered here: once Git realizes it doesn't have to read a work-tree directory, it doesn't bother reading it. As a result, ignoring a subdirectory generally makes it impossible to un-ignore (with ! rules) anything within the subdirectory.
I have temporary files created in separate folders inside my source tree which I would like to ignore. Something like:
project/
|--component/
|--.jazzignore
|--file.src
|--file-9df29e29373e66caef72/
|--file.src.tmp
I already ignore file.src.tmp by extension using .jazzignore, but I would also like to ignore the file-9df29e29373e66caef72/. The folder looks empty in the "Unresolved" category for the component, but since its name changes over time, I cannot ignore it by name.
since its name changes over time, I cannot ignore it by name.
Still, if you know its naming convention, you might consider an ignore pattern:
core.ignore= \
file-*
Note it is non-recursive, you that would ignore any file, folder or symlink named file-... anywhere under component.
Here, that would ignore only file-... directly under component.
Eclipse workspaces often include files or folders, such as compiler output, log files, and so on, that you do not want to place under source control.
You can specify resources or classes of resources to be ignored by Rational Team Concert™ source control. Ignored resources are never checked in.
A .jazzignore file is used to prevent items from being checked into change sets.
A .jazzignore file consists of a series of patterns. Any file, folder, or symbolic link whose name matches a pattern cannot be committed to a change set.
There are two types of patterns in a .jazzignore file:
core.ignore patterns, that are effective in the same directory as the ignore file; and
core.ignore.recursive patterns that affect items in all of the directories below the .jazzignore file.