On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote: > Josh Triplett <josh@xxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html