bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file

[Eli Zaretskii]

> Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 14 May 2015 20:30:26 +0300
> 
> On 05/14/2015 06:51 PM, Stefan Monnier wrote:
> >> May I ask why you have uncommitted changes when you pull (or do
> >> whatever else requires to stash them)?
> 
> My main use case: there are local changes in several configuration 
> files, which I don't ever intend to commit.
> 
> > Typical case:
> > - before committing, I do a final "pull".
> > - the "pull" fails, so I have to stash/pull/unstash
> > - the commit touches several files and has a conflict somewhere.
> 
> To avoid this scenario, I usually commit, and then 'git pull --rebase', 
> which we don't, and shouldn't, recommend.
> 
> >> Why don't you commit them or move them to a branch, or work on
> >> a branch to begin with?
> 
> I think it would be annoying to create a branch for every tiny change.

So: do we have a way of knowing which files had their changes stashed?
Then we could call "git reset" on each one of them, after "stash pop".