Re: [RFC PATCH] Re: Empty directories...

From: David Kastrup <dak@gnu.org>
Date: Jul 20, 2007, 05:53 UTC
Message-ID: <851wf3vcxu.fsf@lola.goethe.zz>
In-Reply-To: <alpine.LFD.0.999.0707191726510.27249@woody.linux-foundation.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 11 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> So the whole notion of "remembering" whether a directory was added 
>> explicitly as an empty directory or not is just not a sensible concept in 
>> git. 
>
> That is true if it is implemented as David suggested, to have a
> phony "." entry in the tree object itself.  The object name of such
> a tree (when it contains blobs and trees underneath) will be
> different from a tree that contains the same set of blobs and trees.
> It would destroy the fundamental concepts of git.

How so?

Show 9 quoted lines

> But you _could_ treat that "should-be-kept-even-when-empty"-ness
> just like we treat executable bit on blobs, I think.
>
> When blobs with the same contents but of different type (REG vs LNK)
> and regular file with or without executable bit are entered in git,
> they all get the same SHA-1 but we can still tell them apart because
> the index and the tree entry have mode bits.  So hypothetically, you
> could introduce "sticky" directory in tree entries to mark "this
> will not go away when emptied".

A tree containing files with and without executable bits will show different SHA-1 sums. There is no reason that this should be different for a tree containing the conceptual "." or not. I won't fight for a specific implementation but if I am going to implement this (and the current lack of enthusiasm points to that) I will not go and duplicate the entire ignore/add/rm/index/repository machinery in order to have a bit rather than an actual "." directory entry.

Most Unix file systems have an honest, physical, down-to-Earth directory entry "." even on disk because it _simplifies_ matters, even though one could special-case "." all throughout and make do without a physical entry in theory.

And, as I explained, "." lends itself perfectly to the gitignore machinery in order to policy projects to track or not track directories.

Show 7 quoted lines

> In a 'tree' object, they might appear as:
>
>         40000 ordinary-directory '\0' 20-byte SHA-1
>         41000 directory-dontremove-even-if-empty '\0' 20-byte SHA-1
>
> In 'index', as your "I'm soft" patch, we do not have to add
> nonsticky kind of tree nodes,

It does not work, since then you can't distinguish

mkdir A touch B git-add A/B

from

mkdir A touch B git-add A

It is very clear that git-rm A/B _mustn't_ leave an empty directory in the first case, and _must_ leave an empty directory in the second case _if_ and only if one tracks directories.

> Obviously, this "sticky" bit will cascade up and make your otherwise
> equivalent parent tree's different,

No, it must not "cascade up".  After

mkdir -p A/B touch A/B/C git-add A/B git-rm A/B

there must be nothing tracked by git. The "sticky" bit does not "cascade up". Its upward effect is only changing the SHA-1 of the tree, like any change below does.

> This will involve a lot of changes, so I would not recommend anybody
> doing so, though.

Neither would I. Why people want to complicate the code base everywhere by avoiding to treat "." like a legitimate entry (as Unix file systems do for a _reason_) is simply a miracle to me.

The framework is pretty much _there_. There is no point in not making use of it and duplicating the whole machinery because we want a "bit set" implementation instead of a file name.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum