Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > More and more I get the impression that this thread is just not worth it. > The problem was solved long ago, and all that is talked about here is how > to complicate things. The problem was not _solved_, it was _worked around_. Adding a .gitignore or whatever other file to mean "the directory exists" is clearly a good workaround, but still, you have to use "git-add $dir/.gitignore" where you really _mean_ "git-add $dir/". I can see no reason for the presence of this .gitignore file other than "err, I've put it here because git doesn't manage empty directories". The fact that you need a FAQ entry for that actually shows there is a problem. You don't have a FAQ for "Q: How to I add a file? A: Use git-add file", you shouldn't need a FAQ for "How do I add a directory", it should just work as expected. You claim it "solves" the problem, but have you ever used an importer like git-svn on a project that uses empty directories as placeholders (I do have this problem in daily life because my colleagues still use SVN)? What is the meaning of this .gitignore file the day you export it to anything outside git? If you ignore problems because they have a workaround, then even CVS can be usable. People have been working around CVS's problems for years, and many people are happy with CVS because they didn't realise that solving problems is better than working around them (See the OpenCVS project ...). Fortunately, git doesn't have as many problems to work around as CVS ;-). I'm happy with the answer "it should be done, but not by me, send a patch", and I can't really complain myself since I did not send a patch, but here, you're complaining about someone who actually starts volunteering to solve the problem, which I can't agree with. -- Matthieu - 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
