Re: Can't git stash after using git add -N

I actually think "silently ignore intent-to-add" was a mistake.
We used to error out at write-tree time, which I think is the
right behaviour--"I know I want to have this path, but I cannot
yet decide with what content" is what the user is telling us when
she says "add -N", so until that indecision is resolved, we
shouldn't write out a tree object out of the index.

On Wed, Mar 16, 2016 at 2:05 PM, Jeff King [off-list ref] wrote:

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

quoted

On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote:

quoted

Josh Triplett [off-list ref] writes:

quoted

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