From: Jeff King <peff@peff.net>
Date: Wed, 16 Mar 2016 21:05:35 GMT
Subject: Re: Can't git stash after using git add -N
Message-ID: <20160316210535.GA2200@sigill.intra.peff.net>
In-Reply-To: <20160316120245.GA15091@cloud>

On Wed, Mar 16, 2016 at 05:02:45AM -0700, Josh Triplett wrote:

> On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote:
> > Josh Triplett <josh@joshtriplett.org> writes:
> > 
> > > As far as I can tell, if I run "git add -N" on a file, and then commit
> > > without adding the file contents, it gets committed as an empty file.
> > 
> > Is that true?  Git once worked like that in earlier days, but I
> > think write-tree (hence commit) would simply ignore intent-to-add
> > entries from its resulting tree.
> 
> Git 2.7.0 does appear to commit an empty file if I commit after git add
> -N.

I don't think this is the case:

  git init
  echo content >file
  git add -N file
  git commit -m "empty?"

  git ls-tree HEAD
  git status

shows that we committed an empty tree. So I see two obvious
possibilities for improvement:

  1. This commit should have failed without --allow-if-empty. We need to
     be more careful about intent-to-add entries when figuring out if
     the commit would be empty or not

  2. I'm not sure if "silently ignore intent-to-add" is the best policy.
     At least a warning ("hey, what did you want to do with these
     entries") seems merited, if not aborting the commit entirely. I
     hesitate on the latter only because perhaps that would mess up
     somebody's legitimate workflow.

-Peff