From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org
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 [thread overview]
Message-ID: <5553F93C.9010205@yandex.ru> (raw)
In-Reply-To: <83zj58jvri.fsf@gnu.org>
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
> 0.1%.
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.
next prev parent reply other threads:[~2015-05-14 1:24 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 12:55 bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Eli Zaretskii
2015-04-18 19:16 ` Dmitry Gutov
2015-04-18 19:31 ` Eli Zaretskii
2015-04-18 21:58 ` Dmitry Gutov
2015-04-18 22:06 ` Dmitry Gutov
2015-04-19 14:30 ` Eli Zaretskii
2015-04-19 16:28 ` Dmitry Gutov
2015-04-19 17:06 ` Eli Zaretskii
2015-04-19 17:38 ` Dmitry Gutov
2015-04-19 18:05 ` Eli Zaretskii
2015-04-19 18:11 ` Dmitry Gutov
2015-04-19 18:25 ` Eli Zaretskii
2015-04-19 18:30 ` Dmitry Gutov
2015-04-19 18:38 ` Eli Zaretskii
2015-04-19 19:27 ` Dmitry Gutov
2015-04-19 19:33 ` Eli Zaretskii
2015-04-20 2:41 ` Stefan Monnier
2015-04-20 14:45 ` Eli Zaretskii
2015-04-20 19:20 ` Stefan Monnier
2015-04-20 19:23 ` Eli Zaretskii
2015-04-21 1:06 ` Stefan Monnier
2015-04-22 1:50 ` Dmitry Gutov
2015-04-22 7:35 ` Eli Zaretskii
2015-05-12 23:13 ` Dmitry Gutov
2015-05-13 13:04 ` Stefan Monnier
2015-05-13 16:20 ` Eli Zaretskii
2015-05-13 16:18 ` Eli Zaretskii
2015-05-14 1:24 ` Dmitry Gutov [this message]
2015-05-14 14:53 ` Eli Zaretskii
2015-05-14 18:00 ` Dmitry Gutov
2015-05-14 18:49 ` Eli Zaretskii
2015-05-14 3:49 ` Stefan Monnier
2015-05-14 14:53 ` Eli Zaretskii
2015-05-14 15:51 ` Stefan Monnier
2015-05-14 17:30 ` Dmitry Gutov
2015-05-14 18:36 ` Eli Zaretskii
2015-05-14 18:48 ` Dmitry Gutov
2015-05-14 18:52 ` Eli Zaretskii
2015-05-14 19:09 ` Dmitry Gutov
2015-05-14 19:33 ` Eli Zaretskii
2015-05-14 20:24 ` Dmitry Gutov
2015-05-14 20:55 ` Stefan Monnier
2015-05-15 7:14 ` Eli Zaretskii
2015-05-15 18:13 ` Stefan Monnier
2015-05-15 18:55 ` Eli Zaretskii
2015-05-15 20:02 ` Stefan Monnier
2015-05-15 20:19 ` Eli Zaretskii
2015-05-15 23:52 ` Stefan Monnier
2015-05-15 23:57 ` Dmitry Gutov
2015-05-16 13:48 ` Stefan Monnier
2015-05-15 23:50 ` Dmitry Gutov
2015-05-16 7:15 ` Eli Zaretskii
2015-05-16 8:03 ` Dmitry Gutov
2015-05-16 8:55 ` Eli Zaretskii
2015-05-16 13:15 ` Dmitry Gutov
2015-05-16 13:53 ` Stefan Monnier
2015-05-16 14:13 ` Dmitry Gutov
2015-05-15 7:10 ` Eli Zaretskii
2015-05-15 7:17 ` Eli Zaretskii
2015-04-22 8:47 ` Richard Stallman
2015-04-22 9:16 ` Eli Zaretskii
2015-04-22 19:59 ` Richard Stallman
2015-04-22 21:32 ` Eli Zaretskii
[not found] <xmqqd1il7lor.fsf@gitster.mtv.corp.google.com>
2016-11-16 0:25 ` Dmitry Gutov
2016-11-16 17:30 ` Eli Zaretskii
2016-11-16 22:45 ` Dmitry Gutov
2016-11-17 15:57 ` Eli Zaretskii
2016-11-17 18:04 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5553F93C.9010205@yandex.ru \
--to=dgutov@yandex.ru \
--cc=20292@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=esr@snark.thyrsus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).