Re: git stash pop not reapplying deletions
- From
- Steve Folly <steve@spfweb.co.uk>
- Date
- Feb 15, 2010, 14:32 UTC
- Message-ID
- <loom.20100215T152932-38@post.gmane.org>
- In-Reply-To
- <201002142308.01704.trast@student.ethz.ch>
Thomas Rast <trast <at> student.ethz.ch> writes:
Show 25 quoted lines
> > On Sunday 14 February 2010 20:45:03 Steve Folly wrote: > > > > I'm not sure if I've found a bug in 'git stash' or if I'm using > > it the wrong way? (This is with git 1.6.6): > > > [eliding a lot everywhere to make it clearer] > > $ git status # correctly shows renames > > # renamed: dira/a -> dirb/a > > # renamed: dira/b -> dirb/b > > # renamed: dira/c -> dirb/c > > $ git stash > > $ git stash pop > > # Changes to be committed: > > # new file: dirb/a > > # new file: dirb/b > > # new file: dirb/c > > # Changed but not updated: > > # deleted: dira/a > > # deleted: dira/b > > # deleted: dira/c > > The problem is that you aren't using --index, but still expecting it > to restore your index. If you change it to 'git stash pop --index', > everything will work as expected.
OK, yep - got it. Thanks.
> Yes, it does stage new files, but that is only to help you: otherwise > you could forget them before committing. >
But that's even more confusing - not using --index only restores *some* of the index. To be honest, that's not really helping - I still have to stage deletions manually.
If not using --index isn't supposed to restore the index, then surely it shouldn't be staging the new files?
Cheers Steve