Can't git stash after using git add -N

Can't git stash after using git add -N

[Josh Triplett]

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

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

[Junio C Hamano]

Josh Triplett <josh@joshtriplett.org> writes:

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

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

[Josh Triplett]

On Tue, Mar 15, 2016 at 04:46:48PM -0700, Junio C Hamano wrote:
> Josh Triplett <josh@joshtriplett.org> writes:
> > 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.

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

[Junio C Hamano]

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.

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

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

[Duy Nguyen]

On Wed, Mar 16, 2016 at 11:51 AM, Junio C Hamano <gitster@pobox.com> 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.

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 NOOOO
[master ce2e4bb] NOOOO
> /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

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

[Josh Triplett]

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.

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

[Jeff King]

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

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

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

[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.

On Wed, Mar 16, 2016 at 2:05 PM, Jeff King <peff@peff.net> wrote:
> 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 <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.
>
> 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

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

[Jeff King]

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