git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [BUG] git stash --keep-index undeletes file
@ 2019-04-16 18:04 Christian Vetter
  2019-04-16 18:48 ` Thomas Gummerer
  0 siblings, 1 reply; 4+ messages in thread
From: Christian Vetter @ 2019-04-16 18:04 UTC (permalink / raw)
  To: git@vger.kernel.org

Steps to reproduce
+ mkdir git-stash-test
+ cd git-stash-test
+ git init
+ touch file
+ git add file
+ git commit -m init
+ git rm file
+ git stash push --keep-index
 
 
Result: 
`git status` gives this output:
> On branch master
> Changes to be committed:
>   (use "git reset HEAD <file>..." to unstage)
> 
>         deleted:    file
> 
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
> 
>         file
 
 
Expected: 
`git status` gives this output:
> On branch master
> Changes to be committed:
>   (use "git reset HEAD <file>..." to unstage)
> 
>         deleted:    file
 
 
Verified on:
+ Windows 10, git version 2.21.0.windows.1 
+ Ubuntu 14.04, git version 2.21.0

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [BUG] git stash --keep-index undeletes file
  2019-04-16 18:04 [BUG] git stash --keep-index undeletes file Christian Vetter
@ 2019-04-16 18:48 ` Thomas Gummerer
  2019-04-16 19:57   ` Christian Vetter
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Gummerer @ 2019-04-16 18:48 UTC (permalink / raw)
  To: Christian Vetter; +Cc: git@vger.kernel.org

On 04/16, Christian Vetter wrote:
> Steps to reproduce
> + mkdir git-stash-test
> + cd git-stash-test
> + git init
> + touch file
> + git add file
> + git commit -m init
> + git rm file
> + git stash push --keep-index
>  
>  
> Result: 
> `git status` gives this output:
> > On branch master
> > Changes to be committed:
> >   (use "git reset HEAD <file>..." to unstage)
> > 
> >         deleted:    file
> > 
> > Untracked files:
> >   (use "git add <file>..." to include in what will be committed)
> > 
> >         file

I think this is the correct result.  --keep-index keeps the changes
that are in the index, in this example that 'file' is deleted, but
restores the working tree to 'HEAD', where 'file' existed.  It's now
showing up as untracked because Git doesn't know about it.

Similarly if you just did 'git stash push' without --keep-index,
'file' would be restored in your working tree, but 'git status' would
report the working tree as clean because it would also be restored in
the index.

> Expected: 
> `git status` gives this output:
> > On branch master
> > Changes to be committed:
> >   (use "git reset HEAD <file>..." to unstage)
> > 
> >         deleted:    file

This is what you get before 'git stash push --keep-index'.  Do you
think the documentation on '--keep-index' is unclear, and could be
improved?  Or why did you think that this is the correct output?

> Verified on:
> + Windows 10, git version 2.21.0.windows.1 
> + Ubuntu 14.04, git version 2.21.0

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [BUG] git stash --keep-index undeletes file
  2019-04-16 18:48 ` Thomas Gummerer
@ 2019-04-16 19:57   ` Christian Vetter
  2019-04-16 21:59     ` Thomas Gummerer
  0 siblings, 1 reply; 4+ messages in thread
From: Christian Vetter @ 2019-04-16 19:57 UTC (permalink / raw)
  To: Thomas Gummerer; +Cc: git@vger.kernel.org

Thank you, Thomas!

Now that you explained this, I do understand the behaviour, and agree that it is correct.
While this seems to be clear with a deeper understanding of git than I have,
it might be a good idea to specifically point this out in the docs in the context of `--keep-index`.
That would have helped me.

This does, however, bring me back to a related issue by which I stumbled across this:
If, in the given scenario, I run `git stash apply`, the file is not removed. `git status` still outputs this:
> On branch master
> Changes to be committed:
>   (use "git reset HEAD <file>..." to unstage)
>
>         deleted:    file
>
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
>
>         file

Can you explain that behaviour as well?
The way I understand it, `git stash push --keep-index; git stash apply` should result in zero change to the output of `git status`.
What am I not getting?


________________________________________
From: Thomas Gummerer <t.gummerer@gmail.com>
Sent: Tuesday, April 16, 2019 20:48
To: Christian Vetter
Cc: git@vger.kernel.org
Subject: Re: [BUG] git stash --keep-index undeletes file

On 04/16, Christian Vetter wrote:
> Steps to reproduce
> + mkdir git-stash-test
> + cd git-stash-test
> + git init
> + touch file
> + git add file
> + git commit -m init
> + git rm file
> + git stash push --keep-index
>
>
> Result:
> `git status` gives this output:
> > On branch master
> > Changes to be committed:
> >   (use "git reset HEAD <file>..." to unstage)
> >
> >         deleted:    file
> >
> > Untracked files:
> >   (use "git add <file>..." to include in what will be committed)
> >
> >         file

I think this is the correct result.  --keep-index keeps the changes
that are in the index, in this example that 'file' is deleted, but
restores the working tree to 'HEAD', where 'file' existed.  It's now
showing up as untracked because Git doesn't know about it.

Similarly if you just did 'git stash push' without --keep-index,
'file' would be restored in your working tree, but 'git status' would
report the working tree as clean because it would also be restored in
the index.

> Expected:
> `git status` gives this output:
> > On branch master
> > Changes to be committed:
> >   (use "git reset HEAD <file>..." to unstage)
> >
> >         deleted:    file

This is what you get before 'git stash push --keep-index'.  Do you
think the documentation on '--keep-index' is unclear, and could be
improved?  Or why did you think that this is the correct output?

> Verified on:
> + Windows 10, git version 2.21.0.windows.1
> + Ubuntu 14.04, git version 2.21.0

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [BUG] git stash --keep-index undeletes file
  2019-04-16 19:57   ` Christian Vetter
@ 2019-04-16 21:59     ` Thomas Gummerer
  0 siblings, 0 replies; 4+ messages in thread
From: Thomas Gummerer @ 2019-04-16 21:59 UTC (permalink / raw)
  To: Christian Vetter; +Cc: git@vger.kernel.org

[please don't top post on this list]

On 04/16, Christian Vetter wrote:
> Thank you, Thomas!
> 
> Now that you explained this, I do understand the behaviour, and agree that it is correct.
> While this seems to be clear with a deeper understanding of git than I have,
> it might be a good idea to specifically point this out in the docs in the context of `--keep-index`.
> That would have helped me.

On second thought, I might have been too quick to jump to conclusions
here, and might have misunderstood --keep-index myself.  I think what
you described here is actually a bug, although it's a pretty long
standing one.  So I'm a bit surprised nobody noticed it before.

Thanks for reporting it.

> This does, however, bring me back to a related issue by which I stumbled across this:
> If, in the given scenario, I run `git stash apply`, the file is not removed. `git status` still outputs this:
> > On branch master
> > Changes to be committed:
> >   (use "git reset HEAD <file>..." to unstage)
> >
> >         deleted:    file
> >
> > Untracked files:
> >   (use "git add <file>..." to include in what will be committed)
> >
> >         file
> 
> Can you explain that behaviour as well?
> The way I understand it, `git stash push --keep-index; git stash apply` should result in zero change to the output of `git status`.
> What am I not getting?

Your interpretation of what should happen sounds like the right
behaviour here, and what actually happens seems incorrect.  I don't
have time to dig into this more right now though unfortunately.

> ________________________________________
> From: Thomas Gummerer <t.gummerer@gmail.com>
> Sent: Tuesday, April 16, 2019 20:48
> To: Christian Vetter
> Cc: git@vger.kernel.org
> Subject: Re: [BUG] git stash --keep-index undeletes file
> 
> On 04/16, Christian Vetter wrote:
> > Steps to reproduce
> > + mkdir git-stash-test
> > + cd git-stash-test
> > + git init
> > + touch file
> > + git add file
> > + git commit -m init
> > + git rm file
> > + git stash push --keep-index
> >
> >
> > Result:
> > `git status` gives this output:
> > > On branch master
> > > Changes to be committed:
> > >   (use "git reset HEAD <file>..." to unstage)
> > >
> > >         deleted:    file
> > >
> > > Untracked files:
> > >   (use "git add <file>..." to include in what will be committed)
> > >
> > >         file
> 
> I think this is the correct result.  --keep-index keeps the changes
> that are in the index, in this example that 'file' is deleted, but
> restores the working tree to 'HEAD', where 'file' existed.  It's now
> showing up as untracked because Git doesn't know about it.
> 
> Similarly if you just did 'git stash push' without --keep-index,
> 'file' would be restored in your working tree, but 'git status' would
> report the working tree as clean because it would also be restored in
> the index.
> 
> > Expected:
> > `git status` gives this output:
> > > On branch master
> > > Changes to be committed:
> > >   (use "git reset HEAD <file>..." to unstage)
> > >
> > >         deleted:    file
> 
> This is what you get before 'git stash push --keep-index'.  Do you
> think the documentation on '--keep-index' is unclear, and could be
> improved?  Or why did you think that this is the correct output?
> 
> > Verified on:
> > + Windows 10, git version 2.21.0.windows.1
> > + Ubuntu 14.04, git version 2.21.0

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-04-16 21:59 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-16 18:04 [BUG] git stash --keep-index undeletes file Christian Vetter
2019-04-16 18:48 ` Thomas Gummerer
2019-04-16 19:57   ` Christian Vetter
2019-04-16 21:59     ` Thomas Gummerer

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).