I'm writing a script that is based on "git stash" and I test it
extensively, which leads to finding a lot of weird corner cases in the
behavior of "git stash".
I've reported one bug already and now I've found two "inconsistencies"
that I'm less sure about. (and that may be related to each other,
which is why I write about them in the same email)
OK, the first one occurs when a file (that existed in the previous
commits) is removed in index but after that re-added without informing
Git about it. (So it's untracked.)
git rm file
echo content >file
git stash push
The untracked file is pushed to the stash despite the flag
"--include-untracked" not being set. It even works like that with
"--no-include-untracked".
This looks like a bug for sure but I found a test "stash rm then
recreate" in "t/t3903-stash.sh", which test for this scenario, so
apparently it isn't for some reason? (Just in case, I'm asking for
confirmation that it's intended. Also, is there a way to disable this
behavior so my script won't trip over it?)
The second scenario is the exact opposite in the sense that a file
(that hasn't existed before) is added in the index and removed in the
workspace.
echo content >file
git add file
rm file
git stash push
After that, the information about the file deletion is lost. The stash
contains the file both in stash@{0} and in stash@{0}^1 and the
workspace is clean after the operation (the file is restored).
This, I'm quite sure, is a real bug and not an intended behavior
(although, I have a tiny doubt after finding the test for the other
situation).
I went ahead and tried to fix it on my own but I don't understand the
intricacies of Git's code well enough so I failed. I did write a test
case, though, which I'll send in the next email (because if I
understand it right, patches are supposed to not have any added text
in their email messages).
Piotr
