All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wesley J. Landaker" <wjl@icecavern.net>
To: David Aguilar <davvid@gmail.com>
Cc: Jay Soffian <jaysoffian@gmail.com>,
	Jakub Narebski <jnareb@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [1.8.0] Tracking empty directories
Date: Wed, 2 Feb 2011 19:21:53 -0700	[thread overview]
Message-ID: <201102021921.53755.wjl@icecavern.net> (raw)
In-Reply-To: <4928FF12-E593-4CDB-AC68-B4078CC5920E@gmail.com>

On Wednesday, February 02, 2011 16:33:09 David Aguilar wrote:
> I don't like where this is going. Users are not always right.
> Touch .gitignore and be done with it.   This is a big change with
> negligible benefits.  I don't understand why this is needed.

I am not usually bothered too much that git doesn't story directories, and 
when I need to do it, I can do the .gitignore trick just like anyone else.

However here are a few reasons that I miss this feature sometimes:

  1) Why WOULDN'T you want to track empty directories? We track empty files: 
isn't that just as pointless? What if git couldn't track empty files and 
automatically removed files when they became empty? Well, I could live with 
that just as well, with some silly workarounds every once in a while (e.g. 
echo empty > some_file).

  2) One of git's best strengths is that it's so easy to interact with other 
SCM software, primarily because git's features are a SUPERSET of other SCMs. 
However, almost every other SCM can track empty directories, except git, 
which makes it much harder to use as universal tool, where I can trust that 
everything will round-trip as well as possible. Also, other SCMs don't want 
".gitignore" files cluttering their repository any more than we want their 
SCM tool's random control files in our repositories.

  3) Forget for a moment the cuddly git idosynchracies that through use we 
have come to know and "love". From a design perspective, does putting and 
tracking, a file called IGNORE in a directory you want to KEEP make sense? 
It's one thing to use "touch .gitignore" in an empty directory to keep it 
*as a workaround*, based on implementation details (i.e. any file in the 
directory will do, but we probably will have a .gitignore anyway eventually, 
so might as well as use that) but it's a strange *design*. =)

  4) On many projects I work on with a huge number of people, the workflow 
is to create a very, very intricate directory hierarchy skeleton, so that 
it's clear to everyone where everything goes and how it is organized, even 
before any work is started. In this case with git, it's annoying to do this 
because there are worthless .gitignore files cluttering up everything, which 
makes it harder to find where there are *actual* ignore rules being applied.

  5) Git not tracking empty directories and the (perceived?) arrogant 
reaction from git experts ("no big deal, just touch .gitignore" -- I've said 
this to people too, since it's the canonical answer, but I always feel a 
little chagrined after hyping up everything git can do) sometimes is just 
one more thing that makes git harder to sell to others, especially when they 
are already in love with Subversion or whatever.

Most of all, think of it this way: maybe git doesn't need to track empty 
directories in order to be awesome, but is there some reason that tracking 
empty directories would make it less awesome?

Anyway, just some thoughts.

  parent reply	other threads:[~2011-02-03  2:22 UTC|newest]

Thread overview: 127+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-31  5:53 What's cooking in git.git (Jan 2011, #06; Sun, 30) Junio C Hamano
2011-01-31 15:08 ` Sverre Rabbelier
2011-02-08 17:48   ` Sverre Rabbelier
2011-02-08 19:27     ` Junio C Hamano
2011-01-31 17:05 ` Planning for 1.7.5 and 1.8.0 Junio C Hamano
2011-01-31 17:06   ` [1.8.0] default "git merge" without argument to "git merge @{u}" Junio C Hamano
2011-01-31 20:14     ` Jeff King
2011-01-31 20:17       ` Junio C Hamano
2011-01-31 20:32         ` Felipe Contreras
2011-01-31 20:50     ` [1.8.0] (v2) " Junio C Hamano
2011-01-31 22:55       ` Jeff King
2011-02-01  0:01         ` Thomas Adam
2011-02-01 18:34         ` Scott Chacon
2011-02-01 20:11           ` moving to a git-backed wiki Jeff King
2011-02-01 22:36             ` Jay Soffian
2011-02-01 22:48               ` J.H.
2011-02-02  9:55                 ` Vincent Hanquez
2011-02-02 10:53                   ` Felipe Contreras
2011-02-02 11:14                     ` Jakub Narebski
2011-02-03  2:24                   ` J.H.
2011-02-03 17:45                     ` Jeff King
2011-02-03 19:06                       ` Sverre Rabbelier
2011-02-04  6:03                         ` Jeff King
2011-02-03 20:34                       ` Felipe Contreras
2011-02-04  6:16                         ` Jeff King
2011-02-04 17:50                           ` Felipe Contreras
2011-02-04 14:34                       ` Joey Hess
2011-02-05  7:00                         ` david
2011-02-04  7:31         ` [1.8.0] (v2) default "git merge" without argument to "git merge @{u}" Thomas Hochstein
2011-02-04 23:01     ` [PATCH/RFC] Add support for merging from upstream by default Jared Hance
2011-01-31 17:07   ` [1.8.0] Unify "pathspec" semantics Junio C Hamano
2011-02-01 14:56     ` Nguyen Thai Ngoc Duy
2011-01-31 20:28   ` [1.8.0] reorganize the mess that the source tree has become Nicolas Pitre
2011-01-31 20:57     ` Junio C Hamano
2011-01-31 21:08       ` Matthieu Moy
2011-01-31 21:33         ` Nicolas Pitre
2011-01-31 21:19       ` Nicolas Pitre
2011-01-31 21:00     ` Jeff King
2011-01-31 21:28       ` Nicolas Pitre
2011-01-31 22:17         ` Junio C Hamano
2011-01-31 22:36           ` João P. Sampaio
2011-01-31 22:37           ` Nicolas Pitre
2011-01-31 23:12         ` Jeff King
2011-02-01  0:29           ` Nicolas Pitre
2011-02-01  1:48             ` Jeff King
2011-02-01  4:05               ` Nicolas Pitre
2011-02-01 12:42                 ` Thomas Rast
2011-02-01 11:14                   ` Jonathan Nieder
2011-02-01 11:22                     ` Jonathan Nieder
2011-02-01 13:08                   ` Nicolas Pitre
2011-02-01 16:02                   ` Nguyen Thai Ngoc Duy
2011-02-01 21:53               ` Junio C Hamano
2011-02-01  0:35           ` Erik Faye-Lund
2011-02-01  1:53             ` Jeff King
2011-02-01  1:00           ` Sverre Rabbelier
2011-02-01  1:57             ` Jeff King
2011-02-01  7:24           ` Jay Soffian
2011-02-01 14:42         ` Andreas Ericsson
2011-01-31 21:59     ` [1.8.0] 't/' is standard name for directory with tests Jakub Narebski
2011-01-31 22:32       ` Nicolas Pitre
2011-02-01  0:12         ` Alex Budovski
2011-02-01  0:33           ` Nicolas Pitre
2011-02-01  0:58             ` Jakub Narebski
2011-02-01  1:15             ` Junio C Hamano
2011-02-02 23:55               ` Sam Vilain
2011-02-01 18:26     ` [1.8.0] split largest remaining scripts, gitk and gitweb Jakub Narebski
2011-02-01 22:15       ` Junio C Hamano
2011-02-01 23:20         ` Jakub Narebski
2011-02-05  3:21     ` [1.8.0] reorganize the mess that the source tree has become Martin von Zweigbergk
2011-01-31 21:44   ` [1.8.0] make two-argument fetch update remote branches Thomas Rast
2011-01-31 22:18     ` Matthieu Moy
2011-01-31 22:24     ` Junio C Hamano
2011-01-31 22:27     ` Eugene Sajine
2011-01-31 23:06       ` Junio C Hamano
2011-01-31 23:39         ` Eugene Sajine
2011-02-01  1:13           ` Junio C Hamano
2011-01-31 23:22     ` Jeff King
2011-02-01  7:04     ` Jay Soffian
2011-02-01 15:58       ` Nguyen Thai Ngoc Duy
2011-02-01 22:09       ` Junio C Hamano
2011-02-01 21:05     ` A Large Angry SCM
2011-02-01 22:39       ` Thomas Rast
2011-02-01 23:25         ` A Large Angry SCM
2011-01-31 21:55   ` [1.8.0] forbid full fetchspecs in git-pull Thomas Rast
2011-01-31 22:38     ` Junio C Hamano
2011-01-31 23:15     ` Dmitry Potapov
2011-02-01 15:14       ` Thomas Rast
2011-02-01 20:23         ` Dmitry Potapov
2011-02-01  3:20   ` Planning for 1.7.5 and 1.8.0 Nguyen Thai Ngoc Duy
2011-02-01  4:16     ` Nicolas Pitre
2011-02-01 14:54     ` [1.8.0] Tag namespaces Marc Branchaud
2011-02-01 15:21       ` Nguyen Thai Ngoc Duy
2011-02-01 18:37   ` [1.8.0] Remove deprecated commands René Scharfe
2011-02-01 22:16     ` Junio C Hamano
2011-02-02  0:57     ` Jonathan Nieder
2011-02-10 19:42       ` René Scharfe
2011-02-10 20:56         ` Jonathan Nieder
2011-02-10 21:08           ` Junio C Hamano
2011-02-12 13:24           ` René Scharfe
2011-02-12 21:04             ` Jonathan Nieder
2011-02-13 23:14             ` Junio C Hamano
2011-02-01 21:41   ` [1.8.0] Handle submodule config options consistently in diff plumbing Jens Lehmann
2011-02-02 11:56   ` [1.8.0] Tracking empty directories Jakub Narebski
2011-02-02 23:23     ` Jay Soffian
2011-02-02 23:33       ` David Aguilar
2011-02-02 23:52         ` Jakub Narebski
2011-02-03  2:21         ` Wesley J. Landaker [this message]
2011-02-03  5:53           ` Jonathan Nieder
2011-02-03 10:07           ` Matthieu Moy
2011-02-05  7:43         ` Pete Harlan
2011-02-05 18:31     ` Thomas Koch
2011-02-05 19:00       ` Sverre Rabbelier
2011-02-05 22:37         ` Jared Hance
2011-02-06 20:41         ` Junio C Hamano
2011-02-06 20:46           ` Sverre Rabbelier
2011-02-06  4:42       ` Nguyen Thai Ngoc Duy
2011-02-02 17:23   ` [1.8.0] git-stash invocation changes Thomas Rast
2011-02-02 17:35     ` Shawn Pearce
2011-02-02 18:15       ` Matthieu Moy
2011-02-02 18:51         ` Thomas Rast
2011-02-09 14:35           ` Pat Notz
2011-02-23 19:54   ` [1.8.0] Don't copy "submodule.<name>.update" to .git/config on submodule init Jens Lehmann
2011-02-23 20:28     ` Junio C Hamano
2011-02-23 22:43       ` Jens Lehmann
2011-02-24  0:34         ` Junio C Hamano
2011-02-24 23:44           ` Jens Lehmann
2011-02-03 11:07 [1.8.0] Tracking empty directories Yann Dirson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201102021921.53755.wjl@icecavern.net \
    --to=wjl@icecavern.net \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jaysoffian@gmail.com \
    --cc=jnareb@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.