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

Previous Next

Full log

Message #130 received at 20292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: esr <at> snark.thyrsus.com, monnier <at> iro.umontreal.ca, 20292 <at> debbugs.gnu.org
Subject: Re: bug#20292: 24.5;
 Saving Git-controlled file with merge conflicts after "stash pop"
 stages the file
Date: Thu, 14 May 2015 21:36:12 +0300

> Cc: esr <at> snark.thyrsus.com, 20292 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> 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".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.