On Sun, 22 July 2007, David Kastrup wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> writes:
>> David Kastrup wrote:
>>
>>> I must be really bad at explaining things, or I am losing a fight
>>> against preconceptions fixed beyond my imagination.
Or you are wrong...
>> I don't understand you, or you don't understand git. "Tree" object
>> in object database (in repository) represents a directory in the
>> working area. There was never any problem with having empty trees in
>> object database, or having links to empty directory in the superdir.
>> We don't have to change anything about object database.
>
> I disagree here. The object database _can_ represent an _empty_
> directory that has been added explicitly, because up to now no
> operations existed that actually left an empty tree. But it can't
> distinguish a _non_-empty directory that has been added explicitly
> from non-empty directory that has not been added explicitly.
True. I forgot about that.
Although I'd rather say that we want distinguish between automatically
cleaned up directory (directory which will be deleted if all files in
it would be deleted, and would be untracked if all tracked files in it
would be deleted), and "sticky" directory, which is explicitely tracked
and have to be explicitely deleted.
The fact that it was added explicitely or non explicitely is orthogonal
to that.
IMHO it would be best to first provide plumbing infrastructure (as e.g.
it was the case of submodule support), then add option to
git-update-index to change the "stickiness"/"autoremoval" status of a
directory (of a tree), and _last_ think about how to change the
porcelain (git-add and git-rm).
[...]
> But in the second case, git must _not_ retain a. So we need to record
> the information that in the first case, a was added explicitly. And
> this can't be done with the current repository layout. It doesn't buy
> us anything that we _have_ a representation available for an _empty_
> tree added explicitly. We need this "added explicitly" information
> for _every_ tree, not just empty ones.
>
> And a perfectly consistent way is to make those trees with an
> explicitly added directory _non-empty_, by virtue of putting a file
> "." in them. This file, of course, exists in every physical
> directory, but we may or may not decide to let it be tracked by git,
> using the gitignore mechanism on the pattern ".". Perfectly
> expedient.
Here we disagree. I think putting "." in a tree as marker of having it
not be automatically deleted when empty, as opposed to marking tree
using filemode in the parent, is not a good idea.
The only advantage to the "." idea is that it can use gitignore
mechanism (both in-tree .gitignore, tracked or not, and info/exclude
file). But I also think that the fact that gitignore mechanism is
recursive is more of disadvantage than advantage.
First, it is _not_ consistent. Working directory trees _always_ have '.'
in them, while trees would have or would have not it, depending if they
would be "sticky" or "autoremoved".
Second, the "easy implementation" is anything but easy. "git add ." as
a way to mark directory as "sticky" is not backward compatibile:
currently it mean to add _all contents_ of current directory.
Implementation is tricky: as we have seen trying to unlink '.' or
create '.' can unfortunately succeed on [some Sun OS, and UFS
filesystem] (which follows POSIX stupidly to the letter) f**king
up the filesystem. The alternative proposal of adding "magic mode" to
mark directory as "not remove when empty" is largely tested; it is very
similar to the subproject support.
Third, is contrary to the git philosophy of tracking contents.
"Stickiness" is an attribute; the fact that directory is explicitely
tracked or not does not change contents of a directory. Compare to
'blob' which contains only contents of a file: not a filename, not a
pathname, not [subset of] filemode.
Fourth, is very artificial. What would you put for filemode for '.'?
040000 (i.e. directory)? What would you put for sha1? Sha1 of an empty
directory? Of an empty blob? 0{40} (which is bad idea because
git-diff-tree uses 0{40} to represent 'not existance')?
>> The problems with git problems with empty directories stems from the
>> fact that index didn't have directories.
>
> That basically implies that no information about directories could be
> tracked in the repository. And yes, we need appropriate information
> in the index. Again, the information whether a directory was added
> explicitly.
Whether directory is automatically managed by git (automatically removed
or untracked). But we need directory entry in index for git-diff, for
example to recognize if there is or there is not empty directory, or if
a directory is automanaged or not.
>> Index is flattened version of root tree, and before subproject
>> support it contained _only_ info about blobs (file contents).
>
> And the repository is a versioned and hierarchically hashed version of
> the index, but its trees contain _no_ information that is not already
> inherently represented by the files alone. [...]
The above sentence is nonsensical. Index is helper for repository,
and can be derived from repository. Not vice versa.
Trees do contain information which is not inherently present by the
blobs.
--
Jakub Narebski
Poland
-
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
