empty directories

empty directories

[Yakov Lerner]

When I git-add empty directory (mkdir d1;git-add d1),
git refuses to add it [1].

I was told on #git chan that git cannot store empty dirs.
But when I do
         git-add -f emptyDir # where emptyDir is empty dir
, emptyDir is added and then cloned. What does it mean ?

Does it mean that if i git-add emptyDir with -f, it may break
something in the repo ? That I shall not try it ? Or it is ok ?

Thanks
Yakov
.....................................................................
[1] $ mkdir emptyDir
$ git-add emptyDir
The following paths are ignored by one of your .gitignore files:
emptyDir (directory)
Use -f if you really want to add them.
$
Note that the printed warning is misleading.
The name (emptyDir) is not in any .gitignore files.
It would be better to print the real reason for ignoring, no ?

Re: empty directories

[Alex Riesen]

On 4/23/07, Yakov Lerner <iler.ml@gmail.com> wrote:
> When I git-add empty directory (mkdir d1;git-add d1),
> git refuses to add it [1].
>
> I was told on #git chan that git cannot store empty dirs.

It can, just refuses to. Which considered good by most

> But when I do
>          git-add -f emptyDir # where emptyDir is empty dir
> , emptyDir is added and then cloned. What does it mean ?

$ git add -f emptyDir
fatal: unable to index file emptyDir

> Does it mean that if i git-add emptyDir with -f, it may break
> something in the repo ? That I shall not try it ? Or it is ok ?

It is not ok and it does not break anything. What git do you
have, as I apparently cannot reproduce it.

Re: empty directories

[Yakov Lerner]

On 4/23/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 4/23/07, Yakov Lerner <iler.ml@gmail.com> wrote:
> > When I git-add empty directory (mkdir d1;git-add d1),
> > git refuses to add it [1].
> >
> > I was told on #git chan that git cannot store empty dirs.
>
> It can, just refuses to. Which considered good by most
>
> > But when I do
> >          git-add -f emptyDir # where emptyDir is empty dir
> > , emptyDir is added and then cloned. What does it mean ?
>
> $ git add -f emptyDir
> fatal: unable to index file emptyDir
>
> > Does it mean that if i git-add emptyDir with -f, it may break
> > something in the repo ? That I shall not try it ? Or it is ok ?
>
> It is not ok and it does not break anything. What git do you
> have, as I apparently cannot reproduce it.

It was 1.5.1.
In 1.5.1.2, it refuses to add, yes.
The message is:
fatal: emptyDir/../emptyDir: can only add regular files or symbolic links

Yakov

Empty directories...

[David Kastrup]

GIT(7) -- 03/05/2007

NAME
	git - the stupid content tracker


Well, I use git for tracking contents.  That means, for example,
installation trees for some application.  Let's take a typical TeXlive
tree as an example.  Those trees contain, among other things,
directories where new fonts/formats/whatever get placed as things run.
Quite a few of them start out empty, but their permissions have to
correspond to their purpose (for example, some are world-writable).

I see little chance to get this achieved without doing something like

find -type d -empty -execdir touch {}/.git-this-is-empty +

before every checkin and

find -name .git-this-is-empty -exec rm -- {} +

after every checkout.  Which is pretty stupid.

As some anecdotal stuff, I did something like

mkdir test
cd test
git-init
touch README
git-add README # another peeve: why is no empty reference point possible?
git-commit -a -m "Initial branch"
git checkout -b newbranch master
unzip ../somearchive -d subdir
git add subdir
git commit -a -m "Add subdir"
git checkout -b newbranch2 master

and expect to have a clean slate.  No such luck: without warning, all
empty directories in the zip file are still remaining within subdir,
which as a consequence has not been cleaned up.

So even if one is of the opinion that empty directories are not worth
putting into the repository: if I check in an entire subdirectory
hierarchy and then switch to a branch where this subdirectory is not
existent, I expect the subdirectory to be _gone_, and not have some
littering of empty directories lying around.

And that git-diff can see nothing wrong with that does not really
improve things.

So if git is supposed to be a content tracker, I can't see a way
around it actually being able to track content, and empty directories
_are_ content.  It can't let them flying around with arbitrary
permissions on them when I switch branches or tags.  And the
workaround using "touch" mentioned above is really awful to do
manually all the time.

Could git technically track a file with a zero-length filename in
empty directories if one tells it explicitly to include it, like with
git-add \! -x "" subdir
or has somebody a better idea or interface or rationale?  I understand
that there are use cases where one does not bother about empty
directories, but for a _content_ tracker, not tracking directories
because they are empty seems quite serious.

Ok, kill me.  This must likely be the most common FAQ/rant/whatever
concerning git.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Empty directories...

[Johannes Schindelin]

Hi,

On Wed, 18 Jul 2007, David Kastrup wrote:

> This must likely be the most common FAQ/rant/whatever concerning git.

If you had the idea already, I wonder why you did not find it.  It's not 
really anything like hard to find:

http://git.or.cz/gitwiki/GitFaq#head-1fbd4a018d45259c197b169e87dafce2a3c6b5f9

Ciao,
Dscho

Re: Empty directories...

[David Kastrup]

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

> Hi,
>
> On Wed, 18 Jul 2007, David Kastrup wrote:
>
>> This must likely be the most common FAQ/rant/whatever concerning git.
>
> If you had the idea already, I wonder why you did not find it.  It's not 
> really anything like hard to find:
>
> http://git.or.cz/gitwiki/GitFaq#head-1fbd4a018d45259c197b169e87dafce2a3c6b5f9

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.

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Empty directories...

[Johannes Schindelin]

Hi,

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.  This is because Git is 
primarily meant to track source code, and most "permissions" (i.e. 
restrictions) do not make any sense there.

> 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.  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.

See the fundamental difference between a file and a directory now?  I 
think it boils down to "an empty directory has _no_ contents, but an empty 
file has an _empty_ content".

Ciao,
Dscho

Re: Empty directories...

[Johannes Schindelin]

Hi,

On Wed, 18 Jul 2007, David Kastrup wrote:

> 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.

> > 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.

> > 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.

> >> 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".

> > 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.

> > 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

Re: Empty directories...

[Matthieu Moy]

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

>> > 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.

I'm not sure it's wrong to be able to track permissions, but it's
definitely wrong to track them by default.

GNU Arch had some permission tracking, and I got hit by it several
times. You have several things you might have wanted to track:

* read/write for the user. But I can't imagine a case where you
  wouldn't want to be able to read and write your own files.

* permissions for group. But that doesn't make any sense when several
  persons work on the same project, and don't share the same
  /etc/group.

* permissions for others. But that, again, doesn't make sense when
  several persons work on the same project with different setups. I
  sometimes work at home, where I'm basically the only user, I don't
  care at all about permissions for others. At work, it's totally
  different, since it's a big NFS shared by all the lab. And I might
  very well disclose my work to the rest of the lab, and work with
  someone who do not want to do so.

* Execute bit. This one is relevant. Indeed, it's more a kind of
  metadata than really a permission (you can still execute the file
  with /lib/ld-linux.so.2 /path/to/file or such kind of things).

Using GNU Arch, I got the cases in real life of a project in which
some files had group read permission, some other not, because they
were created by developers having different umask. Worse than this, I
got some group-writable files in my $HOME without noticing it, which
is basically a security hole.

-- 
Matthieu

Re: Empty directories...

[David Kastrup]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> > 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.
>
> I'm not sure it's wrong to be able to track permissions, but it's
> definitely wrong to track them by default.

I am not sure about "definitely", but there certainly are applications
where it is appropriate.

> * Execute bit. This one is relevant. Indeed, it's more a kind of
>   metadata than really a permission (you can still execute the file
>   with /lib/ld-linux.so.2 /path/to/file or such kind of things).

Please spare us the sophistry.  Probably the most flexible approach
would be to be able to specify a checkout umask, defaulting to 700
(the other bits are then filled in from the normal user umask).  For
archival purposes, one would then set it to 777 instead.

There is the question how to deal with checkins.  While there is no
harm in checking in the full permissions in case one would need them,
it would likely be a nuisance to track the individual contributor's
settings.

-- 
David Kastrup

Re: Empty directories...

[Linus Torvalds]

On Wed, 18 Jul 2007, David Kastrup wrote:
> 
> In the same manner as empty regular files have no contents, and git
> tracks those.  Existence and permissions are important.

Yes, but directories really are different.

First off, git wouldn't track the permissions anyway (git tracks execute 
bits, but for directories that _has_ to be set or git couldn't use them 
itself, so that's not going to happen).

Second, and much more important, the directories will exist or not 
*regardless* of what git does.

> 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.

Bzzt. Wrong.

We *do* remove directories when all files under them go away.

HOWEVER (and this is where one of the reasons for not tracking them comes 
in):

   ** YOU CANNOT REMOVE A DIRECTORY IF IT HAS SOME UNTRACKED CONTENTS **

Think about that for five seconds, then think about it some more. Ponder 
it.

So the fact is, git *already* does ass good of a job as it could possibly 
do wrt directories that go away: it tries to remove them if all the files 
that are tracked in it have gone away.

But that leaves a very common case, namely switching to another branch 
without those files, and the directory still having stale object files etc 
build crud in it.

A SCM *must*not* just remove that directory. It would be horrible. The 
fact that it has untracked files in it does not make those untracked files 
"unimportant". Maybe you feel that way about object files, but what about 
tracking some important parts of your home directory - does the fact that 
you don't necessarily track *all* of it mean that the rest is totally 
unimportant adn that git should just remove it? HELL NO!

So directories really _are_ problematic. You cannot (and should not) track 
them the same way as you track a file.

And the difference is very fundamental indeed: when you track a regular 
file, you track *all* of its content. But when you track a directory, 
you don't track it's content *at*all*.

Think about that, and then think about the fact that git is defined as a 
"content tracker", and it's not "weasely" at all to say that you don't 
track directories.

So your argument is totally bogus. When you track an empty file, you very 
much track the *content* of that file, and "empty" just happens to be a 
very valid content.

But when you track a "directory", you don't actually track its content at 
all, you track it's *existence*, which is a very very very different 
thing. I hope you understand from the above what is so different.

(A true "directory content" tracker by definition would have to track 
every single file under that directory. You can claim that for the case of 
an empty directory the "existence tracking" is 100% equivalent with 
"content tracking", but that's simply not true. It becomes non-true the 
moment there are any files at all inside that directory, and be honest 
now: the only _point_ of an empty directory is that you expect it to 
potentially get files under it).

So "existence" != "content". Git very much does not track "existence" of 
files, it tracks the total content of them too.

			Linus

Re: Empty directories...

[Linus Torvalds]

On Wed, 18 Jul 2007, Linus Torvalds wrote:
> 
> So "existence" != "content". Git very much does not track "existence" of 
> files, it tracks the total content of them too.

Btw, don't get me wrong: I think that in order to be better at tracking 
other SCM's idiotic choices, we could (and I foresee that we eventually 
have to) try to track empty directories as a special case too.

So I'm not _against_ the notion of tracking empty directories, and I would 
welcome patches that do so. As I mentioned in some earlier thread when 
this came up a few weeks ago, I actually suspect that the "subproject" 
support probably ended up making it easier, because in many ways an "empty 
directory" is very close to a "anonymous subproject" from a low-level 
plumbing standpoint (even if it is *not* so from a high-level standpoint).

So I suspect that adding support for empty directories ends up being about 
just slightly extending the places that now have subproject support to 
know about a new situation.

But I do want to point out that "tracking a directory" is not at all the 
same thing as "tracking a file", no matter how much you try to argue 
otherwise. The semantics are totally different, and it all boils down to 
the fact that when you track a file, you are always talking about the 
*full* content of the file, while tracking a directory is always about 
tracking just a *subset* of the contents of the directory.

Of course, with directories, there's the trivial case where the subset 
happens to be everything, but that is neither the common nor the 
interesting case. All the interesting and complex cases happen exactly 
when the directory has untracked files in it, and at that point 

 - you really aren't tracking "contents" any more
 - you can no longer recreate the directory from the data you have (so you 
   cannot remove it on branch switches etc)
 - ergo: you're not a content tracker any more, you're a "container" 
   tracker.

And really, the "nontracked files in a directory" is the *default* thing, 
not some really unusual thing that we could disallow.

But I'm not against adding support for "container tracking". I just want 
people to understand that it's something totally different from what we do 
now. It's much more like subproject support than tracking files.

		Linus

Re: Empty directories...

[David Kastrup]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> But I do want to point out that "tracking a directory" is not at all
> the same thing as "tracking a file", no matter how much you try to
> argue otherwise.

Since I did not try to argue this, could you beat another strawman?
I have seen this prepackaged rant already, but it does not really
address the problem I have been experiencing.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Empty directories...

[Linus Torvalds]

On Wed, 18 Jul 2007, David Kastrup wrote:
> 
> Since I did not try to argue this, could you beat another strawman?

How about a bit of honesty?

Here's the quote:

 "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."

You called it "weaselly" to say that git tracks only content, and then 
very much tried to equate "existence and permissions" with content.

That's the part I answered.

So it wasn't a strawman, it was a direct answer to your assertion. Now go 
away and either come back with the patch to implement it (that I have 
encouraged you to do), or add a ".gitignore" file to the directory (that 
others have told you will solve your problems).

Don't bother talking crap.

			Linus

Re: Empty directories...

[Matthieu Moy]

Linus Torvalds <torvalds@linux-foundation.org> writes:

>> 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.
>
> Bzzt. Wrong.
>
> We *do* remove directories when all files under them go away.
>
> HOWEVER (and this is where one of the reasons for not tracking them comes 
> in):
>
>    ** YOU CANNOT REMOVE A DIRECTORY IF IT HAS SOME UNTRACKED CONTENTS **

I believe David's point was different.

If you checkout a branch, create an empty directory in this branch
(probably a placeholder, either for future versionned files, or for
generated files), you cannot tell git "this empty directory is in this
branch, but not in other ones" without adding a file in it.

So, doing "git-checkout anotherbranch", this empty directory doesn't
go away. It's just unversionned in both branches, git won't touch it.

-- 
Matthieu

Re: Empty directories...

[Linus Torvalds]

On Wed, 18 Jul 2007, Matthieu Moy wrote:
> 
> If you checkout a branch, create an empty directory in this branch
> (probably a placeholder, either for future versionned files, or for
> generated files), you cannot tell git "this empty directory is in this
> branch, but not in other ones" without adding a file in it.

Right. Which is the suggested setup: add an empty ".gitignore" file to the 
directory, and you're done. It now acts "as if" git tracked the directory 
(git will remove the directory when switching branches), but without the 
lie that we really track any directory contents.

			Linus

Re: Empty directories...

[David Kastrup]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, 18 Jul 2007, Matthieu Moy wrote:
>> 
>> If you checkout a branch, create an empty directory in this branch
>> (probably a placeholder, either for future versionned files, or for
>> generated files), you cannot tell git "this empty directory is in this
>> branch, but not in other ones" without adding a file in it.
>
> Right. Which is the suggested setup: add an empty ".gitignore" file
> to the directory, and you're done.

That implies that every directory in a versioned tree will exclusively
be created under manual and conscious control.  Not by running some
installer or script, unpacking some archive and so on.  But if every
content on a disk was created and put there under manual control of
the disk owner, we could still get along with floppy disks quite fine.
In practice, much more content gets sent around and juggled than what
is under immediate supervision of the user.

This is getting silly: you don't need to pull out rabbits out of your
head.  You said that you are not inclined to do any work in that area
since it does not touch _your_ use cases (well, at least not to a
degree that you consider worth bothering about) but that is no reason
to get into ridiculous arguments about other usage.  No code will come
of that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Empty directories...

[Linus Torvalds]

On Wed, 18 Jul 2007, David Kastrup wrote:
>
> You said that you are not inclined to do any work in that area
> since it does not touch _your_ use cases (well, at least not to a
> degree that you consider worth bothering about) but that is no reason
> to get into ridiculous arguments about other usage.

How hard is it for you to admit that I also said "please send in a patch".

I don't need it. You do. You do the work. I'm just explaining why the work 
hasn't been done.

		Linus

Re: Empty directories...

[David Kastrup]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, 18 Jul 2007, David Kastrup wrote:
>>
>> You said that you are not inclined to do any work in that area
>> since it does not touch _your_ use cases (well, at least not to a
>> degree that you consider worth bothering about) but that is no reason
>> to get into ridiculous arguments about other usage.
>
> How hard is it for you to admit that I also said "please send in a
> patch".

Yup, that was one sentence in about 5 pages of bile.  In contrast,
Junio gave a good overview of the technical areas involved here, and
estimates about what to do there best.

That's a constructive way to encite somebody to delve into the task
and try to see whether he can come up with something.

But 5 pages of what amounts to "you are an idiot, come up with a
patch" is not leading anywhere.

> I don't need it. You do. You do the work. I'm just explaining why
> the work hasn't been done.

No, you are _defending_ why the work has not been done.  This
rationalizing around the bush is a waste of time.  You probably have
spent quite more time with your venting than Junio did with his
technical analysis, and the latter has been much more helpful.

So why waste all that time and adrenaline on something where you have
already said all you consider relevant?  The arguments don't get any
stronger by shouting, and it is not like you are inconvenienced in any
manner if somebody takes a look at the matter.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Empty directories...

[David Kastrup]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, 18 Jul 2007, David Kastrup wrote:
>
>> 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.
>
> Bzzt. Wrong.
>
> We *do* remove directories when all files under them go away.

But empty directories which were empty to start with don't go away
since they are not tracked.  And that means that their parents don't
go away.

Git will remove directories which _had_ git-tracked content prior to
the checkout.  But it will not register empty directories created
outside of git, and consequently will not remove them.

> HOWEVER (and this is where one of the reasons for not tracking them
> comes in):
>
>    ** YOU CANNOT REMOVE A DIRECTORY IF IT HAS SOME UNTRACKED CONTENTS **
>
> Think about that for five seconds, then think about it some
> more. Ponder it.

Linus, condescension is all very nice, but I already told you: I had a
directory hierarchy created outside of git's control (every file comes
into being first outside of git).  This hierarchy contained empty
directories.  The while hierarchy was committed into git.  git
silently skipped registering empty directories.  Then a different
version got checked out which did not contain the directory hierarchy
in question.  And git left the (unregistered) empty directories in, as
well as all their parent directories.

And that is just plain wrong.

> So the fact is, git *already* does ass good of a job as it could
> possibly do wrt directories that go away: it tries to remove them if
> all the files that are tracked in it have gone away.

But I told git to track the whole directory tree recursively.  There
were no uncommitted files it complained about.  It is not reasonable
that it is afterwards unable to remove this when I checkout some other
tag.

> A SCM *must*not* just remove that directory. It would be
> horrible. The fact that it has untracked files in it does not make
> those untracked files "unimportant".

Sure.  But that it refuses to track the files makes the total behavior
an annoyance.  I don't complain _how_ git handles not being able to
track empty directories.  I complain about it not being able to track
them in the first place.  The consequences are hideous.

> Maybe you feel that way about object files, but what about tracking
> some important parts of your home directory - does the fact that you
> don't necessarily track *all* of it mean that the rest is totally
> unimportant adn that git should just remove it? HELL NO!

When I tell it to track it, it should not refuse.  Even if it is
empty.  Because if it _stayed_ empty, git can then remove it (and
possibly the parents) when I checkout something else.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Empty directories...

[Matthieu Moy]

David Kastrup <dak@gnu.org> writes:

> or has somebody a better idea or interface or rationale?  I understand
> that there are use cases where one does not bother about empty
> directories, but for a _content_ tracker, not tracking directories
> because they are empty seems quite serious.

,----[ http://www.spinics.net/lists/git/msg30730.html ]
| From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
| 
| I wouldn't personally mind if somebody taught git to just track empty
| directories too.
| 
| There is no fundamental git database reason not to allow them: it's in
| fact quite easy to create an empty tree object. The problems with
| empty directories are in the *index*, and they shouldn't be
| insurmountable.
| 
| [...]
`----

-- 
Matthieu

Re: Empty directories...

[David Kastrup]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> or has somebody a better idea or interface or rationale?  I understand
>> that there are use cases where one does not bother about empty
>> directories, but for a _content_ tracker, not tracking directories
>> because they are empty seems quite serious.
>
> ,----[ http://www.spinics.net/lists/git/msg30730.html ]
> | From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> | 
> | I wouldn't personally mind if somebody taught git to just track empty
> | directories too.
> | 
> | There is no fundamental git database reason not to allow them:
> | it's in fact quite easy to create an empty tree object.
> | The problems with empty directories are in the *index*, and they
> | shouldn't be insurmountable.

Stop right here: does that mean that I can script some "put empty
directories into the last commit manually" procedure bypassing the
index?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Empty directories...

[Shawn O. Pearce]

David Kastrup <dak@gnu.org> wrote:
> > ,----[ http://www.spinics.net/lists/git/msg30730.html ]
> > | From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> > | 
> > | I wouldn't personally mind if somebody taught git to just track empty
> > | directories too.
> > | 
> > | There is no fundamental git database reason not to allow them:
> > | it's in fact quite easy to create an empty tree object.
> > | The problems with empty directories are in the *index*, and they
> > | shouldn't be insurmountable.
> 
> Stop right here: does that mean that I can script some "put empty
> directories into the last commit manually" procedure bypassing the
> index?

Yes.  But when you read that tree into the index later (by say
checking out a branch that points to it) the empty directories
will not be created, as they have no files to cause their creation.
Committing changes on that branch will remove the empty directories.
;-)

Oh, and the above question from you sounds like you think you can
modify the last commit to include new directories that weren't
there before.  You cannot do that without changing the tree SHA-1,
which will cause the commit SHA-1 to change.  That in turns means you
are not actually adding to the last commit but instead are creating
an entirely different commit.  History in Git is always immutable.

-- 
Shawn.

Re: Empty directories...

[Junio C Hamano]

David Kastrup <dak@gnu.org> writes:

> or has somebody a better idea or interface or rationale?  I understand
> that there are use cases where one does not bother about empty
> directories, but for a _content_ tracker, not tracking directories
> because they are empty seems quite serious.

No objections as long as a patch is cleanly made without
regression.  It's just nobody agreed that it is "quite serious"
yet so far, and no fundamental reason against it.

Re: Empty directories...

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
>> or has somebody a better idea or interface or rationale?  I understand
>> that there are use cases where one does not bother about empty
>> directories, but for a _content_ tracker, not tracking directories
>> because they are empty seems quite serious.
>
> No objections as long as a patch is cleanly made without
> regression.  It's just nobody agreed that it is "quite serious"
> yet so far, and no fundamental reason against it.

Thanks.  It certainly is not serious for the Linux kernel source, but
seems awkward for quite a few situations.  Anyway, what is your take
on the situation I described?

That creating some directory hierarchy (happening to contain empty
directories) with some external program, adding and committing it,
then switching to a different branch (or maybe doing a git-reset
--hard) leaves a skeleton of empty directories around?

I find this almost worse than not being able to put them into the
repository: you can't get rid of them anymore either!

I'd be tempted to propose that git should remove empty subdirectories
when cleaning up a removed tree in the working directory, even though
that violates the principle to not delete anything it isn't tracking.
But since you can't get it to track the stuff in the first place...

But the real fix would be to track them.

Does some trick work possibly at checkin time, like putting an empty
file into every empty directory, adding to the index, then removing
all empty files explicitly from the index and then checking in, or is
this hopeless to work around with from the user side without affecting
the repository itself?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Empty directories...

[Wincent Colaiuta]

El 18/7/2007, a las 7:56, David Kastrup escribió:

> That creating some directory hierarchy (happening to contain empty
> directories) with some external program, adding and committing it,
> then switching to a different branch (or maybe doing a git-reset
> --hard) leaves a skeleton of empty directories around?
>
> I find this almost worse than not being able to put them into the
> repository: you can't get rid of them anymore either!
>
> I'd be tempted to propose that git should remove empty subdirectories
> when cleaning up a removed tree in the working directory, even though
> that violates the principle to not delete anything it isn't tracking.
> But since you can't get it to track the stuff in the first place...
>
> But the real fix would be to track them.

Although I haven't yet been "bitten" by this issue I understand where  
you're coming from. This could confuse users and appear inconsistent  
to them (seeing as empty *files* can be tracked). I think it's  
probably worth tackling for that reason alone, but it will have the  
additional benefit of enabling other workflows like the one you  
describe ("installation trees for some application").

> Does some trick work possibly at checkin time, like putting an empty
> file into every empty directory, adding to the index, then removing
> all empty files explicitly from the index and then checking in, or is
> this hopeless to work around with from the user side without affecting
> the repository itself?

I wouldn't recommend any "tricks" here. I think the real solution is  
to allow the tracking of empty trees; everything else seems like a  
kludge. And then, as you've noted already that will allow Git to  
handle the "skeleton of empty directories" left behind problem that  
you describe.

Cheers,
Wincent

Re: Empty directories...

[Junio C Hamano]

David Kastrup <dak@gnu.org> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> No objections as long as a patch is cleanly made without
>> regression.  It's just nobody agreed that it is "quite serious"
>> yet so far, and no fundamental reason against it.
>
> Thanks.  It certainly is not serious for the Linux kernel source, but
> seems awkward for quite a few situations.  Anyway, what is your take
> on the situation I described?

Didn't I say I do not have an objection for somebody who wants
to track empty directories, already?  I probably would not do
that myself but I do not see a reason to forbid it, either.

The right approach to take probably would be to allow entries of
mode 040000 in the index.  Traditionally, we allowed only 100644
(blobs as regular files) and 120000 (blobs as symlinks).  We
recently added 160000 (commit from outer space, aka subproject).

And we do that for all directories, not just empty ones.  So if
you have fileA, empty/, sub/fileB tracked, your index would
probably have these four entries, immediately after read-tree
of an existing tree object:

	100644 15db6f1f27ef7a... 0	fileA
	040000 4b825dc642cb6e... 0	empty
	040000 e125e11d3b63e3... 0	sub
	100644 52054201c2a872... 0	sub/fileB

Making sure that empty/ directory exists in the working tree is
probably done in entry.c; we have been touching that area in an
unrelated thread in the past few days.

If you add sub/fileC, with "update-index" (and "add"), you
invalidate the SHA-1 object name you stored for "sub" (because
there is no point recomputing the tree object until you know you
need a subtree for "sub" part, which does not happen until the
next "write-tree"), and end up with something like:

	100644 15db6f1f27ef7a... 0	fileA
	040000 4b825dc642cb6e... 0	empty
	040000 00000000000000... 0	sub
	100644 52054201c2a872... 0	sub/fileB
	100644 705bf16c546f32... 0	sub/fileC

These "missing" SHA-1 would need to be recomputed on-demand.

We have had necessary infrastructure to do this "keeping
untouched tree object names in the index" for quite some time,
but it is not a part of the index proper (it is stored in an
extension section in the index file, to keep the index
compatible with older versions of git).

Having made it sound so easy, here are the issues I would expect
to be nontrivial (but probably not rocket surgery either).

 * unpack-trees, which is the workhorse for twoway merge (aka
   "switching branches") and threeway merge, has a convoluted
   logic to avoid D/F conflicts; it can probably be cleaned up
   once we do the above conversion so that the index starts
   saying "Hey, I have a directory here" more explicitly.  The
   end result would probably be a code easier to follow.

 * status, update-index --refresh, and diff-files cares about
   the information cached in the index from the last time
   lstat(2) is run on each entry.  What we should store there
   for "tree" entries is very unclear to me, but probably we
   should teach them to ignore the stat-matching logic for
   these entries.

 * diff-index walks the index and a tree in parallel but does
   not currently expect to see a tree object in the index.  It
   needs to be taught to ignore these "tree" entries.

 * merge-recursive and merge-index walk the index, coming up
   with the merge results one path at a time.  They also need to
   be taught to ignore these "tree" entries.

 * diff-index and "read-tree -m" should be taught to take
   advantage of the "tree" entries in the index.  For example,
   if diff-index finds the "tree" entry in the index and the
   subtree found from the tree object exactly match, it does not
   even have to descend into the tree, which would be a huge
   performance win (because you do not have to open the subtree
   and its subtrees from the tree side; you already have read
   everything on the index side, and still have to skip the
   entries in the directory).  "read-tree -m" also should be
   able to optimize two identical subtrees in the 2 or 3 trees
   involved.

   Even if we follow the "lazy invalidate" strategy to maintain
   the "tree" entries in the normal codepath, we could have a
   special operation that says "now update all the tree entries
   by recomputing the tree object names as needed".  Perhaps we
   might want to initiate such an operation before "read-tree
   -m" automatically.

Re: Empty directories...

[Junio C Hamano]

David Kastrup <dak@gnu.org> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Having made it sound so easy, here are the issues I would expect
>> to be nontrivial (but probably not rocket surgery either).
>> ...
> This would seem to imply that the index does not need to be
> upwards-compatible: simplifying the code means that old indexes won't
> be treated all too well.

I did not imply any such thing, by the way.  These are off the
top of my head technical issues and there probably are more, but
I limited the list to technical side of the things.

You of course have social side to take care of.  If you are
breaking everybody else's index, you would need to tell
everybody: "I am sorry but if you upgrade your git to this
version that does what I want, you have to nuke your index and
start over, so commit all changes first, and then update the
git.  Sorry for causing you a minor inconvenience".  Everybody
at this point involves (obviously) the kernel folks, wine,
x.org, among many others.

I suspect your saying that to them is probably not good enough
for them to forgive the minor inconveniences, which means you
need to convince _me_ to join you in defending, in the release
notes, that this is a feature worth having even though there is
a minor inconvenience to redo everybody's index files.  Which I
suspect is quite unlikely to happen at this moment, though...

A much less troublesome approach might be to do things
differently from what I outlined, to keep the index compatible
as long as it does not contain an empty directory, which is what
we did for subprojects support.

Re: Empty directories...

[Johan Herland]

On Wednesday 18 July 2007, Junio C Hamano wrote:
> Didn't I say I do not have an objection for somebody who wants
> to track empty directories, already?  I probably would not do
> that myself but I do not see a reason to forbid it, either.
> 
> The right approach to take probably would be to allow entries of
> mode 040000 in the index.  Traditionally, we allowed only 100644
> (blobs as regular files) and 120000 (blobs as symlinks).  We
> recently added 160000 (commit from outer space, aka subproject).
> 
> And we do that for all directories, not just empty ones.  So if
> you have fileA, empty/, sub/fileB tracked, your index would
> probably have these four entries, immediately after read-tree
> of an existing tree object:

Sorry for jumping in late...

Why do you want to add _all_ directories, and not just the ones we want to 
explicitly track (independent of whether they're empty or not).

Basically, add a "--dir" flag to git-add, git-rm and friends, to tell them 
you're acting on the directory itself (rather than its (recursive) 
contents). "git-add --dir foo" will add the "040000 123abc... 0 foo" to the 
index/tree whether or not foo is an empty directory. "git-rm --dir foo" will 
remove that entry (or fail if it doesn't exist), but _not_ the contents of 
foo.

Since we're making directory tracking _explicit_, this should all be trivially 
backward-compatible.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: Empty directories...

[David Kastrup]

Johan Herland <johan@herland.net> writes:

> On Wednesday 18 July 2007, Junio C Hamano wrote:
>> Didn't I say I do not have an objection for somebody who wants
>> to track empty directories, already?  I probably would not do
>> that myself but I do not see a reason to forbid it, either.
>> 
>> The right approach to take probably would be to allow entries of
>> mode 040000 in the index.  Traditionally, we allowed only 100644
>> (blobs as regular files) and 120000 (blobs as symlinks).  We
>> recently added 160000 (commit from outer space, aka subproject).
>> 
>> And we do that for all directories, not just empty ones.  So if
>> you have fileA, empty/, sub/fileB tracked, your index would
>> probably have these four entries, immediately after read-tree
>> of an existing tree object:
>
> Sorry for jumping in late...

It could have given you a chance to read up on what has already been
discussed.

> Why do you want to add _all_ directories, and not just the ones we
> want to explicitly track (independent of whether they're empty or
> not).

Because the problematic cases are more often than not the _implicit_
cases.  Do you check a directory tree for empty directories before you
archive it?  In order to archive every empty directory explicitly?

If you did that, you could equally maintain a script that manually
does mkdir/rmdir.

> Basically, add a "--dir" flag to git-add, git-rm and friends, to
> tell them you're acting on the directory itself (rather than its
> (recursive) contents). "git-add --dir foo" will add the "040000
> 123abc... 0 foo" to the index/tree whether or not foo is an empty
> directory. "git-rm --dir foo" will remove that entry (or fail if it
> doesn't exist), but _not_ the contents of foo.

There is nothing wrong with implementing something like this in
_addition_ to treating directory entries implicitly.  For example, ls
has an option -d which does just that, and even git-ls-files has an
option --directory.  Heck, I even have

rm --help
Usage: rm [OPTION]... FILE...
Remove (unlink) the FILE(s).

  -d, --directory       unlink FILE, even if it is a non-empty directory
                          (super-user only; this works only if your system
                           supports `unlink' for nonempty directories)
[...]

which works on just the directory and not on the contents.

So a --directory option for appropriate commands would be natural for
_explicit_ manipulation of such entries.

But the important, the _really_ important thing are the implicit
behaviors.  If I have to hassle with every directory myself, I don't
need a content tracking system.

The --directory stuff, in contrast, are things nice to have when the
framework is in place (and may be even necessary for some direct
manual maintenance tasks), but they don't really concern the
framework.

-- 
David Kastrup

Re: Empty directories...

[Johan Herland]

On Friday 20 July 2007, David Kastrup wrote:
> Johan Herland <johan@herland.net> writes:
> > Sorry for jumping in late...
> 
> It could have given you a chance to read up on what has already been
> discussed.

I have tried to keep on top of the discussion so far.

> > Why do you want to add _all_ directories, and not just the ones we
> > want to explicitly track (independent of whether they're empty or
> > not).
> 
> Because the problematic cases are more often than not the _implicit_
> cases.  Do you check a directory tree for empty directories before you
> archive it?  In order to archive every empty directory explicitly?

No, of course I don't. But then archiving (as in tar) is intended to recreate 
the "working copy" exactly as it was. Git (and other SCMs), however, is only 
interested in recreating the part of the working copy it explicitly tracks.

Given the following working copy:
/
/tracked/
/tracked/file
/tracked/dir/
/untracked/
/untracked/file
/untracked/dir/

and the following commands:
$ git add tracked

$ git clone

The cloned result could be any of the following:

(1)
/
/tracked/
/tracked/file

This is the current behaviour; directories are not tracked at all, but only 
added as necessary to support files.

(2)
/
/tracked/
/tracked/file
/tracked/dir/
/untracked/
/untracked/dir/

i.e. implicitly tracking _all_ directories. This is what you literally ask 
for, but I think most would find this unreasonable.

(3)
/
/tracked/
/tracked/file
/tracked/dir/

i.e. recursively tracking directories (and files). This seems useful, but 
there is nothing _implicit_ about this.


I have a feeling that you're actually arguing for doing (3) by default. What I 
am arguing is to do (1) by default, and (3) if given a suitable command-line 
option (i.e. "git add --with-dirs tracked").

Note that this is really an interface question. How these entries are actually 
stored in the repo is a different discussion.


Finally, let's look at the case of "git add tracked/file" followed by "git rm 
tracked/file". I'm arguing that "tracked/" should be automatically removed, 
since I never asked for it to be tracked by git. On the other 
hand, "git-add --non-recursive tracked" followed by the above two commands, 
should of course leave "tracked/" in place, since I now actually asked 
explicitly for the directory to be tracked.

My point is fundamentally that selectively tracking directories is a more 
powerful concept than just tracking _all_ directories by default. Note that 
if we support selectively tracking directories, tracking _everything_ (like 
you seem to want) is trivially implemented by _always_ supplying the 
appropriate option to git-add. If we track everything by design, we don't 
have the option of selectively tracking some directories.


> > Basically, add a "--dir" flag to git-add, git-rm and friends, to
> > tell them you're acting on the directory itself (rather than its
> > (recursive) contents). "git-add --dir foo" will add the "040000
> > 123abc... 0 foo" to the index/tree whether or not foo is an empty
> > directory. "git-rm --dir foo" will remove that entry (or fail if it
> > doesn't exist), but _not_ the contents of foo.
> 
> There is nothing wrong with implementing something like this in
> _addition_ to treating directory entries implicitly.

I don't agree. By _selectively_ tracking directories you can implement any 
policy you want on top of it.

> For example, ls 
> has an option -d which does just that, and even git-ls-files has an
> option --directory.  Heck, I even have

Yes, having commandline options for explicitly specifying directories (and not 
their contents) is _exactly_ what I want.

> But the important, the _really_ important thing are the implicit
> behaviors.  If I have to hassle with every directory myself, I don't
> need a content tracking system.

I disagree. Just as you have to decide which files to track, you similarly 
should have to decide which directories to track. Of course, the tools make 
this easier for you by being able to recursively handle files. In the same 
way they should be able to do the same thing for directories.


Have fun!

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: Empty directories...

[David Kastrup]

Johan Herland <johan@herland.net> writes:

> On Friday 20 July 2007, David Kastrup wrote:
>> Johan Herland <johan@herland.net> writes:
>> > Sorry for jumping in late...
>> 
>> It could have given you a chance to read up on what has already been
>> discussed.
>
> I have tried to keep on top of the discussion so far.
>
>> > Why do you want to add _all_ directories, and not just the ones we
>> > want to explicitly track (independent of whether they're empty or
>> > not).
>> 
>> Because the problematic cases are more often than not the
>> _implicit_ cases.  Do you check a directory tree for empty
>> directories before you archive it?  In order to archive every empty
>> directory explicitly?
>
> No, of course I don't. But then archiving (as in tar) is intended to
> recreate the "working copy" exactly as it was. Git (and other SCMs),
> however, is only interested in recreating the part of the working
> copy it explicitly tracks.

Yes, and
git-add some-dir
tells it to track _everything_ inside some-dir.  Which means that the
included files are tracked _implicitly_.  The included directories
(including some-dir itself) are not.

> Given the following working copy:
> /
> /tracked/
> /tracked/file
> /tracked/dir/
> /untracked/
> /untracked/file
> /untracked/dir/
>
> and the following commands:
> $ git add tracked
>
> $ git clone
>
> The cloned result could be any of the following:
>
> (1)
> /
> /tracked/
> /tracked/file
>
> This is the current behaviour; directories are not tracked at all, but only 
> added as necessary to support files.

And so your case (1) actually rather is a single line:

/tracked/file

Everything else is just part of representing /tracked/file and
disappears as soon as /tracked/file disappears.

> (2)
> /
> /tracked/
> /tracked/file
> /tracked/dir/
> /untracked/
> /untracked/dir/
>
> i.e. implicitly tracking _all_ directories. This is what you literally ask 
> for,

I don't see how you can possibly conclude that from what I have been
writing.

> but I think most would find this unreasonable.

And it is.  So please _don't_ put words into my mouth.  In my
proposal, the following (and nothing else) would get tracked:

/tracked/.
/tracked/file

and that's it.  That is what was requested, and that is what is
tracked.  There will be, incidentally, a tree "/tracked/" and a tree
"/" in the _repository_, but those collapse as soon as they are empty.
They are just an _abstract_ data structuring tool in the repository
that is _mapped_ to directories on checkout.

> /
> /tracked/
> /tracked/file
> /tracked/dir/
>
> i.e. recursively tracking directories (and files). This seems useful, but 
> there is nothing _implicit_ about this.

You did not ask for "/tracked/file" and you did not ask for
"/tracked/dir/" (whatever they may be).  That you wanted to track them
was _implied_ by your request of "/tracked/".

> I have a feeling that you're actually arguing for doing (3) by
> default.  What I am arguing is to do (1) by default, and (3) if
> given a suitable command-line option (i.e. "git add --with-dirs
> tracked").
>
> Note that this is really an interface question.

Not at all.  It is a _conceptual_ question: in order for this to work
at _all_ (instead of being an inconsistent heap of ugly surprises),
directories need a representation in the repo.  This representation,
as opposed to in the work file system, is _optional_: the repository
got perfectly well along without it up to now, and the fallback is
already implemented when there is a tree without corresponding
directory.

> How these entries are actually stored in the repo is a different
> discussion.

Sure.  But anything that requires four dozens of special cases instead
of four because one wanted to keep "things that are under some
specialized view separate separate" is not something I am going to
implement.  I am too old to juggle with complexity for the sake of
complexity.  I can make much more use of the existing infrastructure
by actually making file and directory entries quite similar.

ls -la
also has no special cases for "." and ".." because they are, at a very
fundamental level, very special in achieving a special purpose
_without_ being special-cased.

> Finally, let's look at the case of "git add tracked/file" followed
> by "git rm tracked/file". I'm arguing that "tracked/" should be
> automatically removed, since I never asked for it to be tracked by
> git.

Sure.  And nobody ever said otherwise.  In fact, I gave about a dozen
examples in that line and more special in the thread up to now.

> On the other hand, "git-add --non-recursive tracked" followed by the
> above two commands, should of course leave "tracked/" in place,
> since I now actually asked explicitly for the directory to be
> tracked.

Sure.  Use "--directory" instead of "--non-recursive" and you have a
somewhat more special option for that.

> My point is fundamentally that selectively tracking directories is a
> more powerful concept than just tracking _all_ directories by
> default.

Perhaps you might read up on some of the past discussion before
beating dead horses.  This has been covered already, and more than
once.  I never asked for "all directories" to be tracked.  I outlined
cases where they are tracked and where not, and I tested that the
mechanisms in "man gitignore" already work _perfectly_ with the
pattern "." for configuring the _implied_ tracking at directory,
repository, project, and user preference level.

> Note that if we support selectively tracking directories, tracking
> _everything_ (like you seem to want) is trivially implemented by
> _always_ supplying the appropriate option to git-add. If we track
> everything by design, we don't have the option of selectively
> tracking some directories.

But that means manual intervention all of the time.  It is fine when a
tool provides an option to shoot you in the arm instead of in the foot
as usual, but that's not really a fix, but an acerbation of the
problem.

>> > Basically, add a "--dir" flag to git-add, git-rm and friends, to
>> > tell them you're acting on the directory itself (rather than its
>> > (recursive) contents). "git-add --dir foo" will add the "040000
>> > 123abc... 0 foo" to the index/tree whether or not foo is an empty
>> > directory. "git-rm --dir foo" will remove that entry (or fail if
>> > it doesn't exist), but _not_ the contents of foo.
>> 
>> There is nothing wrong with implementing something like this in
>> _addition_ to treating directory entries implicitly.
>
> I don't agree. By _selectively_ tracking directories you can
> implement any policy you want on top of it.

No, you can't.  Because a "policy" means that things are _implied_.
Being able to do everything manually is not a policy.  It may be a
lifesaver at times, but then you have little business drifting in the
river in the first place.

>> But the important, the _really_ important thing are the implicit
>> behaviors.  If I have to hassle with every directory myself, I
>> don't need a content tracking system.
>
> I disagree. Just as you have to decide which files to track, you
>similarly should have to decide which directories to track. Of
>course, the tools make this easier for you by being able to
>recursively handle files. In the same way they should be able to do
>the same thing for directories.

--directory _explicitly_ is not working recursively, so it does not
solve that problem.

-- 
David Kastrup

Re: Empty directories...

[Johan Herland]

On Friday 20 July 2007, David Kastrup wrote:
> Johan Herland <johan@herland.net> writes:
> > My point is fundamentally that selectively tracking directories is a
> > more powerful concept than just tracking _all_ directories by
> > default.
> 
> Perhaps you might read up on some of the past discussion before
> beating dead horses.  This has been covered already, and more than
> once.  I never asked for "all directories" to be tracked.  I outlined
> cases where they are tracked and where not, and I tested that the
> mechanisms in "man gitignore" already work _perfectly_ with the
> pattern "." for configuring the _implied_ tracking at directory,
> repository, project, and user preference level.

It seems our discussion is based on so many misunderstandings of each other 
that it's not very useful to reply to specific parts of it.

AFAICS, from a high-level POV, we're pretty much in agreement on the following 
points:

1. Git should be able to track directories.

2. Tracked directories should be kept alive, even if empty.

3. Git must not necessarily track _all_ directories.


Conversely, we seem to disagree on these points:

4. Whether or not git should track directories by default. You say yes, I say 
no.

5. How the tracking of directories should be implemented in git's object 
database. I want to keep the index/tree as-is except for adding directory 
entries (w/mode 040000) for the tracked directories only. You seem to want to 
add directory entries for _all_ directories and then additional "." entries 
for directories you don't want deleted if/when empty.


Am I making sense, or have I misunderstood our misunderstandings?


...Johan


-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: Empty directories...

[Johan Herland]

On Friday 20 July 2007, David Kastrup wrote:
> Johan Herland <johan@herland.net> writes:
> 
> > AFAICS, from a high-level POV, we're pretty much in agreement on the
> > following points:
> >
> > 1. Git should be able to track directories.
> >
> > 2. Tracked directories should be kept alive, even if empty.
> >
> > 3. Git must not necessarily track _all_ directories.
> >
> >
> > Conversely, we seem to disagree on these points:
> >
> > 4. Whether or not git should track directories by default. You say
> > yes, I say no.
> 
> Element of least surprise.  But since my proposal allows easy and
> intuitive declaration of the preference at user, project, and
> directory level without one choice messing with the choice of other
> projects and contributors with mixed preferences, this is quite
> unimportant.
> 
> We are in agreement that adding or removing the tracking explicitly
> for a single directory might be useful to have.  But it can't be the
> only way.

As long as you can add/remove tracking recursively for a whole (sub)tree, I 
don't see what's the problem. Of course, if you want to change the default 
behaviour, you should be able either set a config variable somewhere, or - as 
a last resort - alias git-add and git-rm to always supply the appropriate 
command-line option.

> > 5. How the tracking of directories should be implemented in git's
> > object database. I want to keep the index/tree as-is except for
> > adding directory entries (w/mode 040000) for the tracked directories
> > only. You seem to want to add directory entries for _all_
> > directories and then additional "." entries for directories you
> > don't want deleted if/when empty.
> 
> No.  I don't want to change _anything_ for untracked directories.
> They are, as previously, implied by the contents and have a "tree"
> entry for efficiency reasons.  Nothing new here.
> 
> The directory mode entries are named "." and are for tracked
> directories only.

Ok. So our difference in opinion on implementation is even smaller than I 
imagined; basically only whether the directory is tracked by a mode "040000" 
entry, or by a "." entry.

> > Am I making sense, or have I misunderstood our misunderstandings?
> 
> The latter.  You are violently arguing for what I outlined.  Which
> probably shows that I am not the best at explaining my ideas, and that
> it reflects badly upon them.

That probably goes for both of us :)


Well, as long as we have this clarified, I don't see much point in continuing 
this part of the thread. I feel confident that the git community as a whole 
will converge on the best technical solution, once it surfaces.


Have fun!

...Johan


-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: Empty directories...

[David Kastrup]

Johan Herland <johan@herland.net> writes:

> On Friday 20 July 2007, David Kastrup wrote:
>> Johan Herland <johan@herland.net> writes:
>
>> > 4. Whether or not git should track directories by default. You
>> > say yes, I say no.
>> 
>> Element of least surprise.  But since my proposal allows easy and
>> intuitive declaration of the preference at user, project, and
>> directory level without one choice messing with the choice of other
>> projects and contributors with mixed preferences, this is quite
>> unimportant.
>> 
>> We are in agreement that adding or removing the tracking explicitly
>> for a single directory might be useful to have.  But it can't be
>> the only way.
>
> As long as you can add/remove tracking recursively for a whole
> (sub)tree, I don't see what's the problem.

Neither do I.  But a --directory option never is recursive.  That is
the whole point.

Probably we are in violent agreement again.

> Of course, if you want to change the default behaviour, you should
> be able either set a config variable somewhere, or - as a last
> resort - alias git-add and git-rm to always supply the appropriate
> command-line option.

Or declare diverging behaviors using a !. or . entry in the gitignore
mechanisms.  Which work everywhere where we need them.

>> > 5. How the tracking of directories should be implemented in git's
>> > object database. I want to keep the index/tree as-is except for
>> > adding directory entries (w/mode 040000) for the tracked
>> > directories only. You seem to want to add directory entries for
>> > _all_ directories and then additional "." entries for directories
>> > you don't want deleted if/when empty.
>> 
>> No.  I don't want to change _anything_ for untracked directories.
>> They are, as previously, implied by the contents and have a "tree"
>> entry for efficiency reasons.  Nothing new here.
>> 
>> The directory mode entries are named "." and are for tracked
>> directories only.
>
> Ok. So our difference in opinion on implementation is even smaller
> than I imagined; basically only whether the directory is tracked by
> a mode "040000" entry, or by a "." entry.

Actually, even smaller: I'd track them by a "." entry with mode
1777755755 or whatever is the natural expression for "this is a
directory".  The mode would be different from the existing "this is a
tree".

_If_ one wants at one time track permissions of files apart from "x",
the "." entry would be natural for carrying directory permissions.
Without ".", you basically tell git "I don't care about the existence
of this directory.  Just do what is necessary for checking out my
files".

>> > Am I making sense, or have I misunderstood our misunderstandings?
>> 
>> The latter.  You are violently arguing for what I outlined.  Which
>> probably shows that I am not the best at explaining my ideas, and
>> that it reflects badly upon them.
>
> That probably goes for both of us :)
>
> Well, as long as we have this clarified, I don't see much point in
> continuing this part of the thread. I feel confident that the git
> community as a whole will converge on the best technical solution,
> once it surfaces.

I'll probably crank out some insolently primitive proof of concept
eventually.

-- 
David Kastrup

Re: Empty directories...

[David Kastrup]

Coming full circle...

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

> The right approach to take probably would be to allow entries of
> mode 040000 in the index.  Traditionally, we allowed only 100644
> (blobs as regular files) and 120000 (blobs as symlinks).  We
> recently added 160000 (commit from outer space, aka subproject).
>
> And we do that for all directories, not just empty ones.  So if
> you have fileA, empty/, sub/fileB tracked, your index would
> probably have these four entries, immediately after read-tree
> of an existing tree object:
>
> 	100644 15db6f1f27ef7a... 0	fileA
> 	040000 4b825dc642cb6e... 0	empty
> 	040000 e125e11d3b63e3... 0	sub
> 	100644 52054201c2a872... 0	sub/fileB

This would be very much what I am proposing now, except that instead
of 040000 we would have 040755 usually, so that when the index makes
it into the repository where 040000 already has a meaning (a
disappear-when-empty tree) we get the right information.  Also note
that the above comes about when doing
git-add *
but not when doing
git-add fileA empty sub/fileB (in the latter case, the entry for sub
                               would be missing)

> If you add sub/fileC, with "update-index" (and "add"), you
> invalidate the SHA-1 object name you stored for "sub" (because
> there is no point recomputing the tree object until you know you
> need a subtree for "sub" part, which does not happen until the
> next "write-tree"), and end up with something like:
>
> 	100644 15db6f1f27ef7a... 0	fileA
> 	040000 4b825dc642cb6e... 0	empty
> 	040000 00000000000000... 0	sub
> 	100644 52054201c2a872... 0	sub/fileB
> 	100644 705bf16c546f32... 0	sub/fileC
>
> These "missing" SHA-1 would need to be recomputed on-demand.

Ah, ok.  Does it even make sense to compute the SHA-1 values in the
index in advance?  What would they be useful for?

> We have had necessary infrastructure to do this "keeping
> untouched tree object names in the index" for quite some time,
> but it is not a part of the index proper (it is stored in an
> extension section in the index file, to keep the index
> compatible with older versions of git).

What is the application for which this is being used?

> Having made it sound so easy, here are the issues I would expect
> to be nontrivial (but probably not rocket surgery either).
>
>  * unpack-trees, which is the workhorse for twoway merge (aka
>    "switching branches") and threeway merge, has a convoluted
>    logic to avoid D/F conflicts; it can probably be cleaned up
>    once we do the above conversion so that the index starts
>    saying "Hey, I have a directory here" more explicitly.  The
>    end result would probably be a code easier to follow.

I am afraid that this is unlikely to happen, and that is because
directory tracking remains optional at a fundamental level as long as
we want to support the current behavior as an option.  However, one
could conceivably add 040000 entries (rather than 040755) for
directories that have not been passed into tracking but are required
by git, if this simplifies matters.  But it sounds like something that
might complicate working with several different git versions on the
same index.

>  * status, update-index --refresh, and diff-files cares about
>    the information cached in the index from the last time
>    lstat(2) is run on each entry.  What we should store there
>    for "tree" entries is very unclear to me, but probably we
>    should teach them to ignore the stat-matching logic for
>    these entries.

At the current point of time, git tracks just the u+x bit for normal
files, and for directories, there is really nothing worth tracking as
long as no attempt of restoring more mode bits is done.  Modification
times are probably a bit too risky to pay attention to.

>  * diff-index walks the index and a tree in parallel but does
>    not currently expect to see a tree object in the index.  It
>    needs to be taught to ignore these "tree" entries.

Or do something sensible when comparing.  Understood.

>  * merge-recursive and merge-index walk the index, coming up
>    with the merge results one path at a time.  They also need to
>    be taught to ignore these "tree" entries.

Same here.

>  * diff-index and "read-tree -m" should be taught to take
>    advantage of the "tree" entries in the index.  For example,
>    if diff-index finds the "tree" entry in the index and the
>    subtree found from the tree object exactly match, it does not
>    even have to descend into the tree, which would be a huge
>    performance win (because you do not have to open the subtree
>    and its subtrees from the tree side; you already have read
>    everything on the index side, and still have to skip the
>    entries in the directory).  "read-tree -m" also should be
>    able to optimize two identical subtrees in the 2 or 3 trees
>    involved.
>
>    Even if we follow the "lazy invalidate" strategy to maintain
>    the "tree" entries in the normal codepath, we could have a
>    special operation that says "now update all the tree entries
>    by recomputing the tree object names as needed".  Perhaps we
>    might want to initiate such an operation before "read-tree
>    -m" automatically.

Over my head, but it would appear that it can safely left for later.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Empty directories...

[Robin Rosenberg]

(
	I don't know which mail is the best to reply to and I probably missed 
	something in the thread, so bear with me if I'm repeating anything.
)

David. Reconsider "tracking" all directories and what that would give, 
compared to explicitly tracking specific ones and the requires magic entries.

Say we have a config setting that tells git never to remove empty trees. Linus 
patches could be a start for representing trees in the index. As an 
optimization the index could prune trees from the index if they contain 
things as long as the index *effectively* remembers all trees.

Using the patches again we could add empty directories to the index and remove 
them. No directory would be removed automatically, except maybe by a merge.

We would probably have only a few empty directories and new unexpected ones
would only pop up when we remove all blobs from one. Git status could tell us
about them so we will not forget them. It could even tell us about "new" empty
directories, which is probably the most important thing you'd want to know. 

Forgetting to untrack an empty directory would not be a big deal.

Whether to retain empty trees or not should be a repository policy, but an all 
or nothing setting.

-- robin

Re: Empty directories...

[David Kastrup]

Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:

> (
> 	I don't know which mail is the best to reply to and I probably missed 
> 	something in the thread, so bear with me if I'm repeating anything.
> )
>
> David. Reconsider "tracking" all directories and what that would
> give, compared to explicitly tracking specific ones and the requires
> magic entries.

It would be quite a nuisance for a patch-based workflow, since patches
don't talk about the creation and deletion of directories.

The "track only when entered approach" has the advantage that
directories that were only created to accommodate patches will be
removed again when becoming empty.

Of course, once doing "git-add top-level" will level the difference.

> Say we have a config setting that tells git never to remove empty
> trees.

Why wouldn't I have tree/zap removed when doing git-rm tree?

> Linus patches could be a start for representing trees in the
> index. As an optimization the index could prune trees from the index
> if they contain things as long as the index *effectively* remembers
> all trees.

But it doesn't.  If you do git-add tree, optimizing the dir entry away
since tree/zap exists, then subsequently do git-rm tree/zap, of course
there is nothing to do except remove tree/zap, and the tree is gone.

One can't start tracking trees explicitly only when they become empty,
because one can't know whether to track them then.

> Using the patches again we could add empty directories to the index
> and remove them. No directory would be removed automatically, except
> maybe by a merge.

I currently have the problem that

rm -rf *
unzip some-archive
git-add some-archive
git-commit -a -m whatever
git-checkout something else

leaves empty directory skeletons lying around.

> We would probably have only a few empty directories and new
> unexpected ones would only pop up when we remove all blobs from
> one. Git status could tell us about them so we will not forget
> them.

I don't want a source management system to tell me whenever it is
going to annoy me.

> It could even tell us about "new" empty directories, which is
> probably the most important thing you'd want to know.
>
> Forgetting to untrack an empty directory would not be a big deal.
>
> Whether to retain empty trees or not should be a repository policy,
> but an all or nothing setting.

With that approach idea the workflow

"Apply a patch creating something/hello"
"Undo the patch creating something/hello"

will leave something lying around.  For somebody managing hundreds of
directories, that would be a nuisance.

I don't say that a "track all parents automatically" approach would
not have its merits: it would likely prevent some mistakes and be
easily understandable to most users.  But for managing a patch
workflow, it would appear to get in the way.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

empty directories

[Josh England]

Hi,

Git doesn't seem to allow me to add an empty directory to the index, or
even nested empty directories.  Is there any way to do this?  What is
the reasoning?  I've got a use case where having empty directories in my
git repository would be *very* valuable.  Any information and help is
greatly appreciated.

-JE

Re: empty directories

[Sean]

On Tue, 21 Aug 2007 11:14:21 -0600
"Josh England" <jjengla@sandia.gov> wrote:

> Git doesn't seem to allow me to add an empty directory to the index, or
> even nested empty directories.  Is there any way to do this?  What is
> the reasoning?  I've got a use case where having empty directories in my
> git repository would be *very* valuable.  Any information and help is
> greatly appreciated.

Hi Josh,

Git doesn't track empty directories.  There is a brief note about it in
the FAQ:

 http://git.or.cz/gitwiki/GitFaq#head-1fbd4a018d45259c197b169e87dafce2a3c6b5f9

Sean

Re: empty directories

[Josh England]

On Wed, 22 Aug 2007, Linus Torvalds wrote:
> On Wed, 22 Aug 2007, Salikh Zakirov wrote:
> > 
> > Linus Torvalds posted an untested patch in a recent discussion and requested
> > that anyone interested in this functionality continued development and testing.
> 
> That untested patch was seriously broken - it didn't do the sorting of 
> empty directories right. So it would need a lot of other work.
> 
> So I'm firmly back in the "just add a '.gitignore' file to the directory" 
> camp.

Woah.  I just spent much of the morning reading the history of this
thread. My eyes are still bleeding, but I think I'm sufficiently
informed enough to be dangerous.

Without actually sticking my head in the honey pot surrounded by giant
bears, I just want to relate a revision control scenario that I've been
wanting to solve for several years. I deploy/maintain many linux
clusters that each have a single system image to boot all nodes on the
machines. My desire is to shove an *entire* image into a git
repository, and simply have it do the right thing.  Doing so and using
clones/branches/merges to maintain these images would be extremely
useful.  I've attempted this concept with several SCMs using various
workarounds for each but have abandoned each attempt mainly due to
performance issues.  Git shows the best performance by far (to the
point of actually being usable) for this purpose.

Forget about special files as those are almost certainly a lost cause.
I'm willing to use .gitignore in empty directories until a better
solution presents itself.  The main need is for file
ownership/permission, which has been touched on before.  When I clone
an image, I really want an *identical* clone, in every way.  It seems
as though git had this functionality but scrapped it due to issues with
umask and merge type problems?  So the question is:  would there be any
way to bring this functionality back as a non-default configurable
option?  For those of us who need the functionality, we'd be more than
willing to live with some of the side-effects.

The alternatives (involving wrappers and strict policy) just haven't
been idiot-proof enough to be truly viable.  It almost has to be a
built-in capability.  It looks like Nax is doing something close to
this.  Is there anyone else using trying to use git in a similar way?

-JE

PS:  I know this falls outside of git's intended use, but its the
closest thing to something that could work.

Re: empty directories

[Linus Torvalds]

On Wed, 22 Aug 2007, Josh England wrote:
>
> The main need is for file ownership/permission, which has been touched 
> on before.  When I clone an image, I really want an *identical* clone, 
> in every way.  It seems as though git had this functionality but 
> scrapped it due to issues with umask and merge type problems?

Well, git had all permission bits, but never ownership. And yes, using 
more than the one user-x-bit ended up being totally unusable for source 
code, because of different people having different umask, so we 
effectively dropped the permission bits too (although the data format was 
retained, so we could re-introduce then with some flag that says "honor 
all permission bits, not just the x bit").

But the ownership thing we've never even tried to support, since it was so 
obviously not something that was appropriate for a distributed project. So 
if you want an identical clone with ownership and (full) permissions, you 
really do need to have some alternate way to fill in the blanks.

I've argued that ".gitattributes" may be an acceptable alternate, 
especially since ownership is often something that is less than "per 
file", and more often "has certain patterns".

> So the question is:  would there be any way to bring this functionality 
> back as a non-default configurable option?  For those of us who need the 
> functionality, we'd be more than willing to live with some of the 
> side-effects.

Full permissions might be easy enough to resurrect, but since it's still 
pointless without ownership, that really isn't even relevant.

But if .gitattributes would work, you probably could introduce both full 
permissions and ownership rules there. We read git attributes for *other* 
reasons when checking files out _anyway_, ie we need the CRLF attribute 
stuff, so adding ownership attributes would not be at all odd.

		Linus

Re: empty directories

[David Kastrup]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Full permissions might be easy enough to resurrect, but since it's
> still pointless without ownership, that really isn't even relevant.

I'd not call it entirely pointless without ownership: under most
systems, only root can do chown, so for example a private backup of a
home directory usually has unique ownership (and nothing but the
normal ownership could be restored by a user, anyway).

However, once the user is member of more than a single group and
actually makes _use_ of that, we are getting on thin ice.  But at
least different group ownership is usually much better contained (and
thus reconstructible manually in the case of an emergency) as the
permissions are.

Since tracking permissions would be a per-project decision (nothing
else makes any sense), it should be workable to amend the tree records
themselves by adding ownership and ACL and whatever else optionally
right there in-place if one figures out a good syntax for it.

One still needs to come up with a good and flexible way to implement
policies: what kind of permissions/ownership data will be let into the
repository from workdir/pushing, and what won't?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: empty directories

[Josh England]

On Wed, 2007-08-22 at 16:25 -0700, Linus Torvalds wrote:
> But if .gitattributes would work, you probably could introduce both full 
> permissions and ownership rules there. We read git attributes for *other* 
> reasons when checking files out _anyway_, ie we need the CRLF attribute 
> stuff, so adding ownership attributes would not be at all odd.

OK, this looks like it has the desired effect.  commits/pulls/etc catch
and update the execute bit.  I'll try to find how .gitattributes hooks
in.  Any pointers/tips are appreciated.

-JE

RE: empty directories

[Jason Garber]

> But if .gitattributes would work, you probably could introduce both
full 
> permissions and ownership rules there. We read git attributes for
*other* 
> reasons when checking files out _anyway_, ie we need the CRLF
attribute 
> stuff, so adding ownership attributes would not be at all odd.
>
> 		Linus

And as a side-note, it would be quite trivial to write a script to
initially populate a .gitattributes file cleanly (and regen when
needed).

~ JasonG

Re: empty directories

[Jakub Narebski]

[Cc: Josh England <jjengla@sandia.gov>, git@vger.kernel.org]

Josh England wrote:

> [...]  The main need is for file
> ownership/permission, which has been touched on before.  When I clone
> an image, I really want an *identical* clone, in every way.  It seems
> as though git had this functionality but scrapped it due to issues with
> umask and merge type problems?  So the question is:  would there be any
> way to bring this functionality back as a non-default configurable
> option?  For those of us who need the functionality, we'd be more than
> willing to live with some of the side-effects.
> 
> The alternatives (involving wrappers and strict policy) just haven't
> been idiot-proof enough to be truly viable.  It almost has to be a
> built-in capability.  It looks like Nax is doing something close to
> this.  Is there anyone else using trying to use git in a similar way?

Check out (via e.g. http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
wiki page) IsiSetup which is tool to manage configuration files (including
permissions) which uses git as engine, and metastore which is meant as
tool to use in appropriate hook for storing/restoring permissions etc.

And as Linus told you, if you have time to work on it, you can try to
make .gitattributes work for this...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: empty directories

[Jakub Narebski]

Josh England wrote:


> Git doesn't seem to allow me to add an empty directory to the index, or
> even nested empty directories.  Is there any way to do this?  What is
> the reasoning?  I've got a use case where having empty directories in my
> git repository would be *very* valuable.  Any information and help is
> greatly appreciated.

Git does not track empty directories [yet], but you can use empty .gitignore
file trick to mark "empty" directories to be added.

There were some discussion about this on git mailing list (see archives),
and this issue is most probably mentioned on GitFaq page in git wiki.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: empty directories

[Salikh Zakirov]

Josh England wrote:
> Git doesn't seem to allow me to add an empty directory to the index, or
> even nested empty directories.  Is there any way to do this?  What is
> the reasoning?  I've got a use case where having empty directories in my
> git repository would be *very* valuable.  Any information and help is
> greatly appreciated.

While the the other replies provided a historical background of how exactly
git handles directories and why it wasn't storing empty directories,
there is no fundamental reason for empty directories not being stored,
it's just nobody got to implement it.

Linus Torvalds posted an untested patch in a recent discussion and requested
that anyone interested in this functionality continued development and testing.

Design discussion: http://lists-archives.org/git/624494-empty-directories.html
Patch: http://marc.info/?l=git&m=118480075313827&w=2

Johannes Schindelin also posted an alternative implementation, which emulates
empty dirs by adding empty .gitignore placeholder to the index.
http://marc.info/?l=git&m=118484785410247&w=2

You could also read the long discussion of the subtle semantic issues that storing empty
directories introduces in the mail thread accessible from above links.

Re: empty directories

[Linus Torvalds]

On Wed, 22 Aug 2007, Salikh Zakirov wrote:
> 
> Linus Torvalds posted an untested patch in a recent discussion and requested
> that anyone interested in this functionality continued development and testing.

That untested patch was seriously broken - it didn't do the sorting of 
empty directories right. So it would need a lot of other work.

So I'm firmly back in the "just add a '.gitignore' file to the directory" 
camp.

Or you can fake it out entirely by making it an empty subproject, which 
also gives you an empty directory.

			Linus

Re: empty directories

[David Kastrup]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Wed, 22 Aug 2007, Salikh Zakirov wrote:
>> 
>> Linus Torvalds posted an untested patch in a recent discussion and
>> requested that anyone interested in this functionality continued
>> development and testing.
>
> That untested patch was seriously broken - it didn't do the sorting
> of empty directories right.

Well, it depends on where one wants to see directories sorted in the
index: the index sort order does not necessarily need to be the same
as the repository sort order: merge conflict detection could benefit
from sorting the directory "early" in the index.  Of course, this
would mean that one needed to stash away directories temporarily while
processing the index until the corresponding tree in the repository
comes up.

> So it would need a lot of other work.

With either choice of sort order, yes.  One place or the other.

-- 
David Kastrup

Empty Directories

[Trans]

New to git...

Is it true there is no way to track empty directories?

Thanks,
T.

Re: Empty Directories

[Marcus Griep]

Directly, no.  An easy workaround is to drop an empty file
(such as a .gitignore) into the directory and track that.
Then the directory will come along for the ride.

Trans wrote:
> New to git...
> 
> Is it true there is no way to track empty directories?
> 
> Thanks,
> T.
> --
> 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

-- 
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´

Re: Empty Directories

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]

On Fri, Aug 15, 2008 at 05:20:01PM -0400, Trans <transfire@gmail.com> wrote:
> Is it true there is no way to track empty directories?

See the FAQ entry:

http://git.or.cz/gitwiki/GitFaq#head-1fbd4a018d45259c197b169e87dafce2a3c6b5f9

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Empty Directories

[Paul Franz]

T.,
    It is interesting that you post the same thing in the Mercurial and 
git mailing lists. Did you post it in Monotone and other distributed 
version control system mailing list?

Paul Franz

Trans wrote:
> New to git...
>
> Is it true there is no way to track empty directories?
>
> Thanks,
> T.
> --
> 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
>
>   

-- 

-------------------------------------------

There are seven sins in the world.
     Wealth without work.
     Pleasure without conscience.
     Knowledge without character.
     Commerce without morality.
     Science without humanity.
     Worship without sacrifice.
     Politics without principle.

   -- Mohandas Gandhi

-------------------------------------------