Rupinderjeet Singh <rupinderjeet47@xxxxxxxxx> writes: > Yes, thank you for being so through with the example. I understand now. > > I want to ask if you would suggest that local configuration (or any > information required by the project) that is too sensitive to be > tracked in git, should either be kept as 'untracked' files or 'outside > of git repository'. I think it depends on the project and participants may not have control over it if it is ingrained in the project's build structure, but a separate place may likely be more appropriate, as it would reduce the chance of accidental "git add ." adding everything. > With your explanation, am I correct to think that only the following > kind of information is suitable to be put in .gitignore files? > 1. that can be regenerated Yes. > 2. that doesn't matter when it is lost Natural consequence of the above > 3. that isn't used by the files tracked in git repository I do not get this, so I decline to comment ;) Is mylib.o that is "ignored", created from tracked mylib.c source, used by mymain.c source that is tracked, when mymain.o would not link without what mylib.o gives it? Some other SCMs have an extra class "precious" to handle exactly the case you have in mind. You do not accidentally let "git add ." to slurp them into the committed history, but you do want them to be left alone. We don't have it, and that is not because we have any reason to be against having it. It is just it didn't happen. And nobody bothered to explore the ramification of adding the new class yet. We know about "checkout" and other mergy operations and "add", but there probably are trickier interactions with other parts of the existing system that somebody need to carefully go through and make sure it does not introduce funny inconsistencies.
