Re: (revised) What's cooking in git.git (May 2009, #01; Sat, 09)

[Jeff King <peff@peff.net>]

On Sun, May 10, 2009 at 01:48:28PM -0700, Junio C Hamano wrote:

> * jk/maint-add-empty (Tue Apr 28 23:21:01 2009 -0400) 1 commit
>  - add: don't complain when adding empty project root
> 
> When you say "git add ." in an empty directory, you get "No path matches
> ''", instead of "No path matches '.'", and this "fixes" it by hiding the
> error and making the command silently succeed.  Strictly speaking it
> introduces inconsistency, but I think an empty directory is so
> uninteresting special case that not signalling it as an error is Ok.
> 
> Will merge to 'next'.

Actually, it is less invasive than that. It _already_ silently ignores
empty directories, like "mkdir foo && git add foo". And because of the
way we chdir to the project root, that is equivalent to "mkdir foo && cd
foo && git add .".

This just extends the behavior to the project root ("mkdir foo && cd foo
&& git init && git add ."). So arguably it is reducing inconsistency. :)

> * jk/no-no-no-empty-directory (Fri May 8 01:01:17 2009 -0400) 2 commits
>  + parseopt: add OPT_NEGBIT
>  + parseopt: add OPT_NEGBIT
> 
> I somehow botched the commit log message of the top one; it is about
> fixing "ls-files --no-empty-directory".

Too bad it is not possible to rewind 'next'. ;)

> * jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit
>  - Allow --date=local --date=other-format to work as expected
> 
> The one I posted had a few corner-case bugs that was caught with the test
> suite; this one has them fixed.  People did not like the UI so it is kept
> out of 'next'

This one has been sitting for a while. I was one of the complainers. If
there is interest, I can rework it according to our previous discussion
(but I'm beginning to wonder if anybody actually cares about this
patch).

-Peff