Re: Can't git stash after using git add -N
On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote: > Josh Triplettwrites: > > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't git stash after using git add -N
On Wed, Mar 16, 2016 at 02:11:19PM -0700, Junio C Hamano wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't git stash after using git add -N
On Wed, Mar 16, 2016 at 05:02:45AM -0700, Josh Triplett wrote: > On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote: > > Josh Triplettwrites: > > > > > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't git stash after using git add -N
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 Kingwrote: > On Wed, Mar 16, 2016 at 05:02:45AM -0700, Josh Triplett wrote: > >> On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote: >> > Josh Triplett 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't git stash after using git add -N
On Wed, Mar 16, 2016 at 11:51 AM, Junio C Hamanowrote: > Josh Triplett 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. 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) > /tmp $ git init a Initialized empty Git repository in /tmp/a/.git/ > /tmp $ cd a > /tmp/a $ git ci --allow-empty -m 1 [master (root-commit) 4d8aed4] 1 > /tmp/a $ git add -N new fatal: pathspec 'new' did not match any files So far so good.. > /tmp/a $ touch new > /tmp/a $ git add -N new OK let's delete "new" and trigger this problem > /tmp/a $ rm new > /tmp/a $ git ci -m N [master ce2e4bb] N > /tmp/a $ git cat-file commit HEAD|grep ^tree tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 > /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. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't git stash after using git add -N
Josh Triplettwrites: > 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. > 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". >> "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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't git stash after using git add -N
On Tue, Mar 15, 2016 at 04:46:48PM -0700, Junio C Hamano wrote: > Josh Triplettwrites: > > 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? > "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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't git stash after using git add -N
Josh Triplettwrites: > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html