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
Quoted 1 line · Josh Triplett
After using "git add -N", "git stash" can no longer stash:
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.
Quoted 15 lines · Junio C Hamano
Quoted 1 line · Josh Triplett
After using "git add -N", "git stash" can no longer stash:
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).
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?
Quoted 4 lines
"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.
Quoted 2 lines · Josh Triplett
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.
Quoted 2 lines
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".
Quoted 6 lines
Quoted 4 lines
"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.
Quoted 8 lines · Junio C Hamano
Quoted 2 lines · Josh Triplett
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 8 lines
Quoted 2 lines
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 9 lines
Quoted 6 lines
Quoted 4 lines
"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.
Quoted 6 lines · Josh Triplett
Quoted 5 lines · Junio C Hamano
Quoted 2 lines · Josh Triplett
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.
Quoted 6 lines
Quoted 3 lines
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
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.
Quoted 39 lines · Jeff King
Quoted 6 lines · Josh Triplett
Quoted 5 lines · Junio C Hamano
Quoted 2 lines · Josh Triplett
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.
Quoted 6 lines
Quoted 3 lines
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 statusshows 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
Quoted 6 lines · Junio C Hamano
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.
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
Quoted 8 lines · Junio C Hamano
Quoted 2 lines · Josh Triplett
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.
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)
Quoted 1 line
/tmp $ git init a
Initialized empty Git repository in /tmp/a/.git/
Quoted 2 lines
/tmp $ cd a
/tmp/a$ git ci --allow-empty -m 1
[master (root-commit) 4d8aed4] 1
Quoted 1 line
/tmp/a$ git add -N new
fatal: pathspec 'new' did not match any files
So far so good..
Quoted 2 lines
/tmp/a$ touch new/tmp/a$ git add -N new
OK let's delete "new" and trigger this problem
Quoted 2 lines
/tmp/a$ rm new/tmp/a$ git ci -m NOOOO
[master ce2e4bb] NOOOO
Quoted 1 line
/tmp/a$ git cat-file commit HEAD|grep ^tree
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Quoted 1 line
/tmp/a$ git cat-file commit HEAD^|grep ^tree
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
The second commit should not be created. git-commit is somehow fooled that there's changes to commit.
Signature · 1 line
Duy