In one of my repositories nearly all of my code is Python and some HTML.
However, Github thinks otherwise:
What causes that?
You were creating files through a script, with an unintended extension. That is, your script was inserting a dot in the file name.
Simply rename your file my_file_0.5ms to my_file_05ms.txt and it will display the correct languages:
What you could do to fix similar problems in the future is use a script to detect extensions and the total lines of code for each extension.
Solution
GitHub Linguist is the culprit in this situation, but luckily, it can be easily resolved in a number of ways.
Create a .gitattributes file and list patterns that match the files you want to ignore, and then append either linguist-vendored or linguist-documentation.
specific-file.5ms
*.5ms
specific-folder/*
This will remove the files from your GitHub repositories statistics on the next run of Linguist (it may take some time).
Notes
If you'd like to attribute these files to a specific language, you can do that using linguist-language={name}. Full documentation on overriding Linguist can be found here.
You can also run Linguist on your own computer, but note that any changes to .gitattributes will not take effect until you commit to your repository. Linguist will not see changes that exist only in the index.
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 want Git to ignore a file named .wh..wh.aufs in the repo's root directory, because it was generated by my local file system (AUFS). But it doesn't help to place the pattern *.aufs in my ~/.config/git/ignore file, because the repo's root directory also has a .gitignore file with the negation pattern !.*.
Apparently the developers I cloned from want to force-track all files beginning with a dot. I still hope to share changes with them, and don't want to disrupt their arrangements. Without modifying their negation pattern, what's the best way to tell git to ignore my .wh..wh.aufs file?
I read the man page. The precedence policy seems to be working against me, unless there's something reliable I could do on the command line.
Check out the third technique here, maybe?
https://help.github.com/articles/ignoring-files
Adding the rule to .git/info/exclude might work for you.
When it comes to Mercurial;
What exactly is the difference between the following:
Stop Tracking
Ignore
Google Search, SE search brings no clear examples / results on the matter.
Generally speaking, as it isn't clear in what context you came across those terms:
Ignore adds a file name pattern to the .hgignore file. It means any files matching the pattern will not be version controlled unless they have already been added (by hg add or hg addrem). So any files that are already part of the repository will not be affected by .hgignore.
Stop Tracking (hg remove or hg forget) means that Mercurial will not record any changes made to the file and the file will no longer be part of the repository. If the file is still present in the file system, it will show up as ? (not tracked). This action takes effect with the next commit, not immediately.
We're having a compatibility problem between Mercurial and another synchronization product (MS Office Groove, now Sharepoint Workspace 2010). Basically, the ".hg" folder and ".hgignore" files are being blocked (I've summarized the issue with the other software).
We've been told that the only work-around is to change the name of the folder. Is there any way to modify Mercurial's naming convention for the database folder and ignore file? From what I understand, I'd just need to make the names more "normal" by adding a prefix. Sort of a "Hail Mary" but thought I'd ask.
You can use a different file name for .hgignore (or more accurately have no .hgignore and then use an ignore= line in your hg/hgrc file to reference an additional ignore file with whatever name you want). However you can't use an alternative name for .hg itself.
As Lasse suggests you shouldn't be synchronizing .hg directories externally anyway. Their read/write/lock semantics are very specific and the only reading/writing to them should be via hg itself. It's very easy to set up a cron job that automatically pushes to a backup repo as often as you'd like.
The names are hard-coded in the Mercurial source, search for occurrences of ".hg" and ".hgignore" (for added safety, also using single quotes). However, since a typical Mercurial installation provides the Mercurial source code, it's easy to change this to anything you prefer.