Can't git stash after using git add -N

After using "git add -N", "git stash" can no longer stash:

/tmp/temp$ git init
Initialized empty Git repository in /tmp/temp/.git/
/tmp/temp$ echo a > a
/tmp/temp$ git add a
/tmp/temp$ git commit -m 'Initial commit of a'
[master (root-commit) d7242c4] Initial commit of a
 1 file changed, 1 insertion(+)
 create mode 100644 a
/tmp/temp$ echo b > b
/tmp/temp$ git add -N b
/tmp/temp$ git stash
error: Entry 'b' not uptodate. Cannot merge.
Cannot save the current worktree state

- Josh Triplett

Josh Triplett <josh@joshtriplett.org> writes:

I think this is unfortunately one of the fundamental limitations that comes from the way how "stash" is implemented. It uses three tree objects (i.e. HEAD's tree that represents where you started at, the tree that results by writing the index out as a tree, and another tree that would result if you added all the changes you made to the working tree to the index and then writing the resulting index out as a tree), but there are some states in the index that cannot be represented as a tree object. "I know I would eventually want to add this new path, but I cannot decide with what contents just yet" aka "git add -N" is one of them (the other notable state that cannot be represented as a tree object is paths with unresolved conflicts in the index).

"git rm --cached" the path and then running "stash save" would be a workaround, but then you'd probably need to use "--untracked" hack when you run "stash save" if you are stashing because you are going to do something to the same path in the cleaned-up working tree.

On Tue, Mar 15, 2016 at 04:46:48PM -0700, Junio C Hamano wrote:

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. Could stash save it exactly as if I'd done "git add" of an empty file at that path and then filled in the contents without adding them?

Right; I do specifically want to save the working-tree files.

Josh Triplett <josh@joshtriplett.org> writes:

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.

As I said, there is no space for a tree object to say "this one records an empty blob but it actually was an intent-to-add entry" and "this other one records an empty blob and it indeed is an empty blob". So "stash pop" (or "stash apply") would fundamentally be unable to resurrect the exact state after "add -N".

Then "git add" that path before "stash save" would probably be a better workaround.

On Wed, Mar 16, 2016 at 11:51 AM, Junio C Hamano <gitster@pobox.com> wrote:

We have at least one problem, probably because of the confusion in diff code (I haven't checked further), which may be fixed once i re-fix d95d728 (diff-lib.c: adjust position of i-t-a entries in diff - 2015-03-16)

Initialized empty Git repository in /tmp/a/.git/

[master (root-commit) 4d8aed4] 1

fatal: pathspec 'new' did not match any files

So far so good..

OK let's delete "new" and trigger this problem

[master ce2e4bb] NOOOO

tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904

tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904

The second commit should not be created. git-commit is somehow fooled that there's changes to commit.

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

Git 2.7.0 does appear to commit an empty file if I commit after git add -N.

How completely crazy would it be to use a non-standard mode bit for that?

I ended up using rm --cached and stash -u, which worked OK, though I then had to manually restore the add -N state.

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

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

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 <peff@peff.net> wrote:

On Wed, Mar 16, 2016 at 02:11:19PM -0700, Junio C Hamano wrote:

Yeah, I am inclined to agree, and I _thought_ we also used to error out during write-tree, but I failed to find the spot where we switched (thinking that it might provide some rationale).

I think I just didn't look far enough back, though. Commit 3f6d56d (commit: ignore intent-to-add entries instead of refusing, 2012-02-07) does not exactly have a sneaky title.

-Peff