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

From: Josh Triplett <josh@joshtriplett.org>
Date: Mar 16, 2016, 02:00 UTC
Message-ID: <20160316020000.GB12130@cloud>
In-Reply-To: <xmqq8u1j7193.fsf@gitster.mtv.corp.google.com>

On Tue, Mar 15, 2016 at 04:46:48PM -0700, Junio C Hamano wrote:

Show 15 quoted lines

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