[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file
Date: Sun, 19 Apr 2015 19:28:40 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

On 04/19/2015 05:30 PM, Eli Zaretskii wrote:

I suggested one method below; perhaps there are others, I simply don't
know enough about Git.

Apparently, we misunderstand each other. By "this case", do you mean when merging a stash in general?

Because I've described a more specific case (popping a stash when one has staged changes in one of the involved files), and it looked like you were referring to it in >>best not to run "git add" in the first place<<.

Stashed changes were uncommitted before, so they should stay
uncommitted after, I think.  Having them staged means the situation
after "stash pop" is different than it was before "stash save", which
I think is not what the user expects.

Right. And I meant the difference between what we do depending on whether user has something staged originally.

If you are questioning the wisdom of doing "stash drop", then this
question is not for me: it wasn't my suggestion.

You said "yes". I asked about this in the context of consistency; the question was about how far will we go to be consistent with Bzr, and whether it's feasible to do so, or we should stop at some point.

If we are not sure
dropping the stash automatically is what the user wants, let's not
drop it, and leave management of stashes to the user.  It's not a big
deal to leave the stash behind, I think.

It's not that big a deal to leave marking files as resolved to the user either. Am I right to understand that's what you're currently suggesting, at least when dealing with stashes?

This is easy (so, done).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]