Thread (6 messages) 6 messages, 4 authors, 2016-06-15

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

From: Josh Triplett <josh@joshtriplett.org>
Date: 2016-06-15 23:08:45

On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote:
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.
quoted
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?
quoted
quoted
"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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help