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

[Josh Triplett <josh@joshtriplett.org>]

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.

> > 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?
> 
> 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".

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

> >> "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.
> >
> > Right; I do specifically want to save the working-tree files.
> 
> Then "git add" that path before "stash save" would probably be a
> better workaround.

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