$ echo foo > bar
$ git add -N bar
$ ./git --exec-path=$PWD stash save
bar: not added yet
fatal: git-write-tree: error building trees
Cannot save the current index state
Maybe it would require some magic in git-stash to detect/save/restore that
particular state, or "just" to cause "add -N" to insert an empty file
instead ?
I suspect that second solution would not be particularly popular, but I
don't find the 1st one very appealing, it just looks like breaking the
whole idea behind git-stash :)
On Fri, Aug 28, 2009 at 01:02:23PM +0200, Yann Dirson wrote:
$ echo foo > bar
$ git add -N bar
$ ./git --exec-path=$PWD stash save
bar: not added yet
fatal: git-write-tree: error building trees
Cannot save the current index state
Maybe it would require some magic in git-stash to detect/save/restore that
particular state, or "just" to cause "add -N" to insert an empty file
instead ?
Yes, there needs to be some magic in git-stash to handle this. There are
actually two calls to write-tree: one to save the index and one to save
the working tree. I think the working tree one should be OK, because we
"git add -u" right beforehand, which means "intent-to-add" files will
be saved properly.
For the index case, we unfortunately cannot represent the situation in
the index using a tree, which means we cannot have a stash that doesn't
lose information. So we have to choose either dropping those index
entries, inserting them as blank files, or inserting them with
working-tree contents.
When you apply the stash, if they were:
- dropped, then you may be surprised to find that those files are now
untracked
- inserted as working-tree content, then you may not realize that you
had not _actually_ added that content to the index earlier, and just
commit it
- inserted as blank files, then you may be a bit surprised by the fact
that it looks like you added a blank version, but at least you will
still see a diff against the working tree file, alerting you to the
fact that maybe they weren't entirely ready for commit.
So I think of the three, the last one is the least surprising. The other
option is to die and force the user to resolve the issue, which is what
we do now. It does actually tell you the problem "bar: not added yet",
though we could perhaps improve on that message a bit. I think that
would require a new 'ls-files' flag to list intent-to-add files.
-Peff
On Fri, Aug 28, 2009 at 03:05:31PM -0400, Jeff King wrote:
For the index case, we unfortunately cannot represent the situation in
the index using a tree, which means we cannot have a stash that doesn't
lose information. So we have to choose either dropping those index
entries, inserting them as blank files, or inserting them with
working-tree contents.
Actually, you _could_ try representing the information by shoe-horning
it into the tree. For example, by allocating a bit of the mode as
"intent-to-add". That seems pretty ugly to me, though.
You could also try to stick the information in the stash's commit
message and recreate it during "stash apply". But again, that feels kind
of ugly.
-Peff