[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 04:24:12 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 05/13/2015 07:18 PM, Eli Zaretskii wrote:

Report a bug in Git, I think.

I believe it's your turn to report a Git bug now. ;)

Still, even if it's fixed, we'll have a lot of users, for years to come, that use Git without that fix. Note how you and I are using quite different versions, and the latest release is 2.4.1.

> It doesn't make sense to have the
outcome of "stash pop" wrt the index/staging depend on whether there
were conflicts or not, which is what happening here: if I "stash pop"
after pulling when none of my local stashed changes are in conflict
with the pulled/merged content, I get back modified and unstaged
files.  Why would the existence of conflicts during "stash pop"
produce any different effect for files _without_ conflicts, except by
some obscure bug?

As a wild guess, maybe the files that get staged automatically are the result of automatic conflict resolution (there was some divergence, but it was resolved automatically; maybe the "no divergence" case is also treated like this, for simplicity). IOW, the "worse is better" kind of reasons.

Unstage the automatically-staged files?

If we can do that, yes.  But how do we know which files to unstage?

That the the difficulty: right after applying the stash we could know (all of them!), but Emacs can't know whether the user staged anything else between then and now (when all conflicts have been resolved). IOW, the user is better positioned to call 'git reset'.

No!  That'd be a step back.  The current treatment of stashed changes
is better than it was before the change.  Also note that conflicts
like this are quite rare, so the way vc-git worked previously was
wrong in 99% of cases, why the one we have now is wrong in perhaps

I don't know where you got the percentages. My stashes routinely touch multiple files, and it's easy to imagine how not all of them could have conflicts after applying.

The odds are hard to calculate, but the probability really must be in tens of percents, not below one.

The current behavior is bad because it looks random. It would look especially random to someone who's used to interact with Git via command-line.

It seems to me we've uncovered a bug in Git (gasp!).  Git has no
reasons to want the changes staged, certainly not depending on whether
there were conflicts.

Staging changes is the Git way to mark conflict as resolved. Ergo, it expects the conflicting files to be staged after the user resolves the conflicts. Then it won't make a lot of sense to leave the rest of the files unstaged, would it? Maybe that's the reasoning.

It's hard for me to tell without knowing exactly why Git conflates conflict resolution and staging.

reply via email to

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