# Strange case with stash

4 messages from 2010-04-10 to 2010-04-12. Participants: Khaled al Habache, Charles Bailey.
Thread: https://gitlist.dev/t/23414

## Khaled al Habache, 2010-04-10 18:04

Subject: Strange case with stash
Message-ID: <v2w918f64e01004101104xd4f1b4eciec01d2e87691ee72@mail.gmail.com>
URL: https://gitlist.dev/e/v2w918f64e01004101104xd4f1b4eciec01d2e87691ee72%40mail.gmail.com

```
Hey,

I have faced this scenario, which is best described
http://stackoverflow.com/questions/2613956/strange-git-case, I hope
you guys investigate it cause it wasted 5 hours of my time, and I
don't wish that happens again to anyone using Git.

-------------------------------
Khaled alHabache
Software Engineer

Blog:
http://www.khelll.com

Rails Magazine:
http://www.railsmagazine.com/team

Twitter:
http://twitter.com/khelll

Mobile:
+963933727070
+962785257212

```

## Charles Bailey, 2010-04-10 18:14

Subject: [PATCH 1/2] stash bug: stash can lose data in a file removed from the index
Message-ID: <1270923241-14383-1-git-send-email-charles@hashpling.org>
URL: https://gitlist.dev/e/1270923241-14383-1-git-send-email-charles%40hashpling.org
In-Reply-To: <v2w918f64e01004101104xd4f1b4eciec01d2e87691ee72@mail.gmail.com>

```
If a file is removed from the index and then modified in the working
tree then stash will discard the working tree file with no way to
recover the changes.

This can might be done in one of a number of ways.

git rm file
vi file              # edit a new version
git stash

or with git mv

git mv file newfile
vi file              # make a new file with the old name
git stash

Signed-off-by: Charles Bailey <charles@hashpling.org>
---
 t/t3903-stash.sh |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 476e5ec..c85bf44 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -228,4 +228,13 @@ test_expect_success 'stash --invalid-option' '
 	test bar,bar2 = $(cat file),$(cat file2)
 '
 
+test_expect_failure 'stash git rm' '
+    git reset --hard &&
+	git rm file &&
+	echo bar7 > file &&
+	git stash &&
+	git stash apply &&
+	test bar7 = $(cat file)
+'
+
 test_done
-- 
1.7.1.rc0.266.gf3d756

```

## Charles Bailey, 2010-04-10 18:14

Subject: [PATCH 2/2] stash: Don't overwrite files that have gone from the index
Message-ID: <1270923241-14383-2-git-send-email-charles@hashpling.org>
URL: https://gitlist.dev/e/1270923241-14383-2-git-send-email-charles%40hashpling.org
In-Reply-To: <v2w918f64e01004101104xd4f1b4eciec01d2e87691ee72@mail.gmail.com>

```
---

This patch is deliberately not signed off. It feels kludgy and uses a
non-portable xargs invocation.

It is designed as a starting point for discussion, that is all.

 git-stash.sh |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index 908aab2..9efc544 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -87,6 +87,8 @@ create_stash () {
 			export GIT_INDEX_FILE &&
 			git read-tree -m $i_tree &&
 			git add -u &&
+			{ git diff --quiet --diff-filter=D --cached ||
+				git diff -z --name-only --diff-filter=D --cached | xargs -0 git add --ignore-errors; } &&
 			git write-tree &&
 			rm -f "$TMP-index"
 		) ) ||
-- 
1.7.1.rc0.266.gf3d756

```

## Charles Bailey, 2010-04-12 21:44

Subject: Re: [PATCH 1/2] stash bug: stash can lose data in a file removed from the index
Message-ID: <20100412214403.GA27958@hashpling.org>
URL: https://gitlist.dev/e/20100412214403.GA27958%40hashpling.org
In-Reply-To: <1270923241-14383-1-git-send-email-charles@hashpling.org>

```
On Sat, Apr 10, 2010 at 07:14:00PM +0100, Charles Bailey wrote:
> If a file is removed from the index and then modified in the working
> tree then stash will discard the working tree file with no way to
> recover the changes.
> 
> This can might be done in one of a number of ways.
> 
> git rm file
> vi file              # edit a new version
> git stash
> 
> or with git mv
> 
> git mv file newfile
> vi file              # make a new file with the old name
> git stash

I just wanted to give this issue a bit more visibility. To me it would
seem to be fairly important as it's a potential loss of user data with
no easy recovery.

If I'm wrong about it, perhaps someone can put me right.

Thanks,

Charles.

```
