Gustaf Hendeby <hendeby@xxxxxxxxxx> writes: > .... I don't want to include > these files in a .gitignore as they are named differently on different > systems. Hence, I include them in my .git/info/exclude file,... I don't have a strong opinion on the submodules part of your issue, but the above part applies to projects with or without submodules, which I have an opinion, and because it is different from what I used to teach people, I think it is worth mentioning.. I used to say "Never place *~ (or *.swp) in .gitignore because they are only useful to you who use Emacs (or vim); and do have *.o in .gitignore, because everybody who compile your checkout would see it". But I don't think the former is a right attitude. My thinking these days is that keeping these in .gitignore should not just be tolerated but should be actively encouraged, unless the project may need to track paths that match *~ or *.swp in the future, If it is very unlikely that the project will ever track them, there is no harm done [*1*], and it will help other people because they don't have to add the same and common entries in their own .git/info/excludes file. I am suspecting that your "these files ... are named differently on different systems" may fall into the same category. Your build may not produce "frotz.linux" when compiled on a FreeBSD box (and "frotz.fbsd" on a Linux box), but would it hurt more than it helps to list them in the same .gitignore to cover both? [Footnote] *1* Once it starts doing so, un-ignoring a special case can be done at that point in the history -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html