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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Simon 'corecode' Schubert <corecode@xxxxxxxxxxxx> writes:

> David Kastrup wrote:
>> But I also want to have directories represented within git, because
>> not doing so leads to awkward problems.  And the proper way as I see
>> it is _not_ to mess with trees and stick them with "stay when empty"
>> flags or similar.  This messes up the whole elegance of git's flat
>> name space.  The proper way is to create a distinct object that
>> represents a physical directory.  We don't need to represent the
>> contents of it: those are already tracked in the flat namespace fine,
>> with trees serving as an implementation detail.
>>
>> All we need to represent is ".".
>
> What I still don't get is: How do you carry this information about
> "this directory should not be removed" from one checkout to the next
> commit?

I don't.  The only information in the file system is whether a
directory exists or not.  "Should not removed" is not a property that
is tracked.

> When creating a .gitignore, this file exists in the workdir.  Of
> course you add some data to the index to stage it.  But how does
> this work with your "." "file"?  You can't put that in the
> filesystem.

Either the directory is in the file system or it is not.  Like with
every other file.  And either git tracks the directory, in which case
it will notice its addition (when doing git-add) and removal (when
doing git-rm or git-commit -a) or git doesn't track the directory.

When git tracks the directory (a matter of gitignore settings for
implicit tracking, and git-add for explicit tracking), and considers
it existent, it will not touch it.  If it tracks it but considers it
removed in particular commit, it will attempt to remove it.

    Fineprint: actually, things are more involved here: git does not
    actually attempt to remove directories at the time it deletes them
    from the tree: this is sort of pointless since the sort order
    means that there might still be files it needs to take out from
    the physical directory).  Instead, like before, git attempts to
    remove a physical directory whenever the corresponding tree in git
    becomes empty, and it is a prerequisite to delete a possibly
    tracked directory from it.

After it has attempted to remove it, it will leave it alone since it
is now no longer tracking it.  If you add and remove a contained file,
it will again try to remove the directory.  If you add _both_
directory and a contained file, just removing the contained file will
not make git attempt to delete the directory.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux