Thread (3 messages) flat view 3 messages, 2 authors, 2016-06-15

Re: [PATCH] git-status: Show empty directories

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:54:02

Leila [off-list ref] writes:
quoted
Having said all that, I personally doubt this is a useful change.  I
may have thought of adding a README file to a relatively new project that
does not yet have one while in shower but I haven't even created the
file in the working tree.  And I forget about it once I get to the
office.  Should the system remind me to create README and then add?
Your patch would not give me such a reminder once the top-level
directory is populated (because it is no longer empty).  Even if I
were planning to add Documentation/README instead, I would get such
a reminder only if the Documentation directory is empty. Once the
directory is populated, I wouldn't get "create README and then add".
Why should an empty directory so special?
So there are two separate discussions here:
1) Should empty dirs be tracked

2) Should empty dirs appear under 'untracked' in git status
You are not answering my question by asking either these two
questions.

Please read what you quoted again.  I may have forgotten to create
and add README

 - at the toplevel directory; or

 - in the Documentation directory that already has other tracked
   files; or

 - in the Documentation directory that does not have any file yet.

Why do I get a reminder for only the last case?  Also please realize
that at no point in the scenario I am interested in adding an empty
directory.  "How does one add empty directories" is irrelevant to my
question.

A more reasonable answer would have been "the reminder is not about
a yet-to-be-created README file, but is about an empty directory you
might have wanted to place something---there is no way for Git to
guess that you wanted the new file to be README, but at least having
a totally empty directory laying around may be an indication that
you wanted to do something intereseting in it but haven't yet".  If
the proposed commit log message justified the behaviour to treat
only the third one specially that way, I suspect it may make some
sense.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help