Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html