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

[Dmitry Gutov <dgutov@yandex.ru>]

On 05/14/2015 05:53 PM, Eli Zaretskii wrote:

> So we do turns on this?

Why not? You seem to have a better idea why this behavior is necessarily 
a bug.

> I only have an old version because there's no newer one for Windows,
> and I can't be bothered enough to build my own.

Then it'll even more likely that a lot of users will be on the "old 
version".

> Anyway, the fact that it takes a long time for a fix to percolate
> shouldn't preclude us from reporting it.

Hopefully, if and when there's a fix, Emacs's behavior won't have to 
change much. But if Git grows a different "resolve a conflict" workflow, 
we'll try to honor it.

> No, I reproduced this when some of the stashed files were not changed
> at all upstream, i.e. there shouldn't have been a need for any
> conflict resolution, automatic or otherwise, in those files.

Then the guess from the end of the message you're replying to, might be 
closer to the truth.

> _My_ wild guess is that Git simply invokes the same code as is used in
> a "normal" merge, and that one stages files that are without conflicts.

Right, or that.

> The user is always better positioned, but we'd like VC to DTRT in the
> more popular situations where the user could be saved from the
> nuisance of figuring things out and typing shell commands.  That's the
> main goal of VC, isn't it?

If we can do that without introducing inconsistencies, losing 
information, or surprising a lot of users.

> If we know all the stashed files, how about invoking "git reset" for
> all of them?  It cannot hurt, can it?

How will we know it? Emacs could try to list all staged files, but 
there's no good way to know that they all belong to the applied stash 
(looking at the top stash isn't reliable either: the user might have 
specified a different one explicitly).

> I'm talking about conflicts, not about the number of files.  How many
> times did you have conflicts in "stash pop"?

Often. But that's irrelevant: in all cases when we don't have a conflict 
when applying a stash, this bug does not apply.

So we should be discussing the percentage of "conflict in only some of 
the files" out of "conflict when applying the stash" situations.

>> The odds are hard to calculate, but the probability really must be in tens of percents, not below one.
>
> Now I wonder where did _you_ get your percentages.

I'm simply basing it on the assumption that a stash likely touches 
multiple files (and that depends on the project/language/environment, so 
it could be frequently false in certain old-school "a few files, each of 
them huge" C projects).

If the stash does touch several files, and there's a conflict, it's easy 
to imagine that the conflict would be only in some of them.

> I agree it's bad, but only if (a) there are multiple changed files,
> and (b) some, but not all, of them have conflicts.

Which is a fairly common situation, like described above.

> By contrast, the previous behavior was always
> wrong.

It was non-ideal, but apparently it was consistent with how a person 
usually works with Git.

>> Staging changes is the Git way to mark conflict as resolved.
>
> Not for uncommitted changes that were stashed, it ain't.

It is. Everywhere the documentation talks about resolving a conflict, 
the documented next step is 'git add'. Nowhere it talks about doing 
something else after resolving a stash conflict.

I'd love to be proved wrong, though.

> For "normal"
> merge conflicts, yes, because a conflict-free merge would have
> committed the changes, so staging is a step in the right direction.
> But for conflicts in stashed uncommitted changes, it's a step in the
> wrong direction, especially in files that didn't have conflicts at
> all.

Here you're talking about your own intention, not about the usual Git 
workflow. Yes, it might be suboptimal, but we might have to live with it 
anyway.

> It's a flawed reasoning, IMO.  I stashed the changes because they are
> not yet ready to be committed, and I wanted them out of my way for a
> while.  When I pop the stash, I want them uncommitted as they were
> before.

Sure, that's why it's suboptimal. But apparently at some point a 
decision was made to handle "normal" merge conflicts and the stash 
conflicts in the same way.

I may be wrong about this: the Git mailing list is a better place to ask.