[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: |
Eli Zaretskii |
Subject: |
bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file |
Date: |
Sun, 19 Apr 2015 20:06:14 +0300 |
> Date: Sun, 19 Apr 2015 19:28:40 +0300
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: esr@snark.thyrsus.com, 20292@debbugs.gnu.org
>
> 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?
I meant when "git stash pop" reports conflicts, in particular after a
"git pull" or "git merge".
> 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<<.
I think we were talking about the same use case, but I cannot be sure,
since "has staged changes" might me more general than what I had in
mind.
> > 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.
Before "git stash save"? The case I had in mind didn't have anything
staged before that.
> > 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".
Yes, because someone more knowledgeable than myself said it was a good
idea.
> 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.
I think it's okay to leave the stash and not drop it in this case.
> > 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?
What does it mean to "mark files as resolved" when the conflict comes
from stashed changes that were uncommitted before "stash save"?
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Eli Zaretskii, 2015/04/10
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Dmitry Gutov, 2015/04/18
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Eli Zaretskii, 2015/04/18
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Dmitry Gutov, 2015/04/18
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Dmitry Gutov, 2015/04/18
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Eli Zaretskii, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Dmitry Gutov, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file,
Eli Zaretskii <=
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Dmitry Gutov, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Eli Zaretskii, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Dmitry Gutov, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Eli Zaretskii, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Dmitry Gutov, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Eli Zaretskii, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Dmitry Gutov, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Eli Zaretskii, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Stefan Monnier, 2015/04/19
- bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file, Eli Zaretskii, 2015/04/20