[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: Thu, 14 May 2015 21:00:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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

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

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.

reply via email to

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