Hi,

On Wed, 18 Jul 2007, David Kastrup wrote:

quoted text
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Wed, 18 Jul 2007, David Kastrup wrote:
> >
> >> The FAQ answer is weazeling on several accounts:
> >> 
> >> a) No, git only cares about files, or rather git tracks content and
> >>    empty directories have no content.
> >> 
> >> In the same manner as empty regular files have no contents, and git
> >> tracks those.  Existence and permissions are important.
> >
> > We do not track permissions of directories at all.
> 
> Ok, this seems like something that should be done as well, even if we
> can stipulate at first that a directory should have rwx for the user
> in question if you hope to track it.

No, no, no.  It should not be tracked.  It is the responsibility of the 
_user_ to set it to something sane, be that by a umask or by sticky 
groups, or by setting the permissions of the parent directory.

It is _nothing_ we want to put into the repository.  That is the _wrong_ 
place to put it.

quoted text
> > This is because Git is primarily meant to track source code,
> 
> Tell that to the man page.  It declares git to be "a content tracker" 
> right at the front.

Why don't you?  I have no problems with the title.

quoted text
> > and most "permissions" (i.e.  restrictions) do not make any sense
> > there.
> 
> So why are permissions for files being tracked, then?

This question is invalid.  Git only tracks the _executable_ bit.  And 
again, it is the users' responsibility, by setting the umask, to have the 
appropriate bits set for group and others.

quoted text
> >> b) The problem is not just that empty directories don't get added 
> >> into the repository.  They also don't get removed again when 
> >> switching to a different checkout.  When git-diff returns zero, I 
> >> expect a subsequent checkout to not leave complete empty hierarchies 
> >> around because git can't delete any empty leaves which it chose not 
> >> to track.
> >
> > I _like_ the behaviour that Git does not remove a directory it
> > added, when I put some untracked file into it.
> 
> But it does not remove a directory it _refused_ to add when there were
> no files at all in it ever.  You probably have not read the problem
> description carefully.

I have.  But that does not apply here, because I used the term "to add a 
directory" in the sense of "mkdir".

quoted text
> > And switching back to that branch, Git has no problems, because it 
> > sees that the directory is already there.  In case of a file, it would 
> > complain, and rightfully so.
> 
> And if you switch to a branch where the directory it did not remove now 
> is a file?

Git already throws an error, and rightfully so.  I am pleased by the 
current behaviour.

quoted text
> > See the fundamental difference between a file and a directory now?
> 
> Condescension is not really solving a problem.

Hey, I only tried to help clarify things.

But since I seem to be unable to, I'll end my efforts with this 
suggestion:

If you want to track empty directories, the best thing would be to

- teach git-add to automatically create an empty .gitignore (and error out 
  if that already exists), and

- teach git-archive to not put .gitignore files into the output by default 
  (but the directories).  This might be a sensible change regardless if 
  you want to add empty directories to the repository or not.

Ciao,
Dscho

-
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