|
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).
[Prev in Thread] | Current Thread | [Next in Thread] |