git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Empty directories...

From
Johan Herland <johan@herland.net>
Date
Jul 20, 2007, 10:20 UTC
Message-ID
<200707201220.15114.johan@herland.net>
In-Reply-To
<86hcnzxy9a.fsf@lola.quinscape.zz>
On Friday 20 July 2007, David Kastrup wrote:
Show 5 quoted lines
> 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.
Show 7 quoted lines
> > 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.

Show 9 quoted lines
> > 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
Previous: David KastrupNext: David Kastrup
Message 98 of 137 in “Empty directories...”
  1. David KastrupJul 18, 2007
  2. Johannes SchindelinJul 18, 2007
  3. David KastrupJul 18, 2007
  4. Johannes SchindelinJul 18, 2007
  5. Linus TorvaldsJul 18, 2007
  6. Linus TorvaldsJul 18, 2007
  7. David KastrupJul 18, 2007
  8. Linus TorvaldsJul 18, 2007
  9. Matthieu MoyJul 18, 2007
  10. Linus TorvaldsJul 18, 2007
  11. David KastrupJul 18, 2007
  12. Linus TorvaldsJul 18, 2007
  13. David KastrupJul 18, 2007
  14. Re: Empty directories...Linus Torvalds, Jul 18, 2007
  15. Linus TorvaldsJul 18, 2007
  16. David KastrupJul 18, 2007
  17. Linus TorvaldsJul 19, 2007
  18. Junio C HamanoJul 19, 2007
  19. Shawn O. PearceJul 19, 2007
  20. David KastrupJul 19, 2007
  21. Geoff RussellJul 19, 2007
  22. Shawn O. PearceJul 19, 2007
  23. Matthieu MoyJul 19, 2007
  24. Tomash BrechkoJul 19, 2007
  25. David KastrupJul 19, 2007
  26. Tomash BrechkoJul 19, 2007
  27. David KastrupJul 19, 2007
  28. NixJul 23, 2007
  29. David KastrupJul 23, 2007
  30. NixJul 23, 2007
  31. NixJul 23, 2007
  32. Jakub NarebskiJul 23, 2007
  33. NixJul 25, 2007
  34. David KastrupJul 23, 2007
  35. Linus TorvaldsJul 23, 2007
  36. NixJul 23, 2007
  37. Linus TorvaldsJul 23, 2007
  38. David KastrupJul 19, 2007
  39. David KastrupJul 19, 2007
  40. Johannes SchindelinJul 19, 2007
  41. David KastrupJul 19, 2007
  42. Brian GernhardtJul 19, 2007
  43. Johannes SchindelinJul 19, 2007
  44. Brian GernhardtJul 19, 2007
  45. Johannes SchindelinJul 19, 2007
  46. David KastrupJul 19, 2007
  47. Brian GernhardtJul 19, 2007
  48. Johannes SchindelinJul 19, 2007
  49. David KastrupJul 19, 2007
  50. Matthieu MoyJul 19, 2007
  51. David KastrupJul 19, 2007
  52. David KastrupJul 19, 2007
  53. David KastrupJul 19, 2007
  54. David KastrupJul 21, 2007
  55. Linus TorvaldsJul 21, 2007
  56. Linus TorvaldsJul 21, 2007
  57. David KastrupJul 21, 2007
  58. Linus TorvaldsJul 21, 2007
  59. David KastrupJul 21, 2007
  60. Simon 'corecode' SchubertJul 21, 2007
  61. David KastrupJul 21, 2007
  62. Linus TorvaldsJul 21, 2007
  63. David KastrupJul 22, 2007
  64. Linus TorvaldsJul 22, 2007
  65. David KastrupJul 22, 2007
  66. Linus TorvaldsJul 22, 2007
  67. David KastrupJul 22, 2007
  68. Linus TorvaldsJul 22, 2007
  69. David KastrupJul 22, 2007
  70. david@lang.hmJul 22, 2007
  71. David KastrupJul 22, 2007
  72. Linus TorvaldsJul 22, 2007
  73. David KastrupJul 22, 2007
  74. Linus TorvaldsJul 22, 2007
  75. Linus TorvaldsJul 22, 2007
  76. David KastrupJul 22, 2007
  77. Jakub NarebskiJul 22, 2007
  78. David KastrupJul 22, 2007
  79. Jakub NarebskiJul 22, 2007
  80. David KastrupJul 22, 2007
  81. Jakub NarebskiJul 22, 2007
  82. David KastrupJul 22, 2007
  83. David KastrupJul 23, 2007
  84. David KastrupJul 23, 2007
  85. David KastrupJul 22, 2007
  86. Brian GernhardtJul 22, 2007
  87. David KastrupJul 28, 2007
  88. David KastrupJul 18, 2007
  89. Matthieu MoyJul 18, 2007
  90. David KastrupJul 18, 2007
  91. Shawn O. PearceJul 18, 2007
  92. Junio C HamanoJul 18, 2007
  93. David KastrupJul 18, 2007
  94. Wincent ColaiutaJul 18, 2007
  95. Junio C HamanoJul 18, 2007
  96. Johan HerlandJul 20, 2007
  97. David KastrupJul 20, 2007
  98. Johan HerlandJul 20, 2007
  99. David KastrupJul 20, 2007
  100. Johan HerlandJul 20, 2007
  101. David KastrupJul 22, 2007
  102. Robin RosenbergJul 26, 2007
  103. David KastrupJul 27, 2007
  104. Johannes SchindelinJul 18, 2007
  105. Matthieu MoyJul 18, 2007
  106. David KastrupJul 18, 2007
  107. Junio C HamanoJul 18, 2007
  108. Brian GernhardtJul 19, 2007
  109. David KastrupJul 19, 2007
  110. Brian GernhardtJul 19, 2007
  111. Junio C HamanoJul 20, 2007
  112. Linus TorvaldsJul 20, 2007
  113. Linus TorvaldsJul 20, 2007
  114. Junio C HamanoJul 20, 2007
  115. Linus TorvaldsJul 20, 2007
  116. David KastrupJul 20, 2007
  117. David KastrupJul 20, 2007
  118. Linus TorvaldsJul 20, 2007
  119. David KastrupJul 20, 2007
  120. Simon 'corecode' SchubertJul 20, 2007
  121. David KastrupJul 20, 2007
  122. Junio C HamanoJul 20, 2007
  123. David KastrupJul 20, 2007
  124. Linus TorvaldsJul 20, 2007
  125. Johan HerlandJul 20, 2007
  126. Linus TorvaldsJul 20, 2007
  127. Julian PhillipsJul 20, 2007
  128. Linus TorvaldsJul 21, 2007
  129. David KastrupJul 21, 2007
  130. David KastrupJul 21, 2007
  131. David KastrupJul 20, 2007
  132. Olivier GalibertJul 20, 2007
  133. Johan HerlandJul 20, 2007
  134. David KastrupJul 20, 2007
  135. David KastrupJul 21, 2007
  136. David KastrupJul 22, 2007
  137. NixJul 24, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.