Andreas Krey <a.krey@xxxxxx> writes: > On Tue, 10 Apr 2012 22:59:39 +0000, Phillip Susi wrote: > ... > > Yes, there are a number of ways you can get to the situation where > > you can not pop the stash. How to resolve this is unclear from > > the results of the failed pop. I finally ended up resolving it by > > committing the remaining changes, then popping the stash ( which > > performed the merge successfully ), and finally doing a git reset > > HEAD~1 to remove the temporary commit, but preserve the merged > > results. This seemed like a good deal of unnecessary trouble. > > (Late to the game.) Actually, this is exactly what I would have proposed > to do. Git is a bit shy on performing a merge into a locally modified > file. I assumed so far that is because there is no way of aborting > such a merge (resetting to the state of local modifications before the > attempt). With the temporary commit you have a way of retrying the pop > merge if you lost your way in it. It would be nice if a.) git gave this advice when unable to "git stash pop" (or "git stash apply") for newbie users, and b.) this solution was put in documentation including git-stash(1) manpage. > And I think that is a good idea; I never liked the way in which a cvs/svn > update merged into locally modified files without a way to undo, and > thus forcing you to clean up the potential mess manually. (Ok, they leave > the old files lying arond, but that doesn't help rewinding the state.) BTW. I sometimes wonder if Mercurial's transaction-based approach isn't a superior solution... > Andreas > > -- > "Totally trivial. Famous last words." > From: Linus Torvalds <torvalds@*.org> > Date: Fri, 22 Jan 2010 07:29:21 -0800 -- Jakub Narebski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html