Re: [PATCH] reset: --unmerge

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 26, 2016, 17:06 UTC
Message-ID: <xmqq1sz3ca4u.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACsJy8Dn7m2axEFkkQtnZMs2yzFwivAJyZCWxODg-HQ=qLnVMA@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 12 quoted lines

> Interestingly the thread/bug that resulted in that commit started with
> "report this bug to git" [2]. Something about git-stash. I quote the
> original mail here in case anyone wants to look into it (not sure if
> it's actually reported here before, I don't pay much attention to
> git-stash mails)
>
> -- 8< --
> Bad news, everyone!
>
> When a stash contains changes for several files, and "stash pop"
> encounters conflicts only in some of them, the rest of the files are
> stages automatically.

It indeed is curious.

That is the designed behaviour for _ANY_ mergy operation, and not limited to "stash pop".

A clean application is added to the index so that you can find out about them from "diff --cached", while conflicted ones keep their unmerged stages so that the conflict can be resolved in the working tree files. There is no bad news here.

Once you resolve the conflict, you would add the final contents to the working tree, but as anybody who knows how "git diff" after resolving conflicts in the working tree files is useful would know, "saving the editor buffer after removing conflict markers" is not a valid signal that the user is confident that the contents is final.

Show 5 quoted lines

> At least, that happens with Git 2.1.0 on my machine, and some
> commenters here: http://stackoverflow.com/a/1237337/615245
>
> So then when we unstage the files which had conflicts after resolving
> those, the result is mixed. Which doesn't look right.

Whoever wrote this does not understand how mergy operations in Git works, I guess.

> What shall we do? Unstage the automatically-staged files? Revert the
> changes from this bug? It seems Git really wants the changes staged
> after the conflict resolution.

The first order of business is to learn how mergy operations in Git is designed to work, and if they are in the business of building a tool around Git to make the life of users better, avoid going against the designed workflow.

If this "Bad news, everyone!" is why vc-git-resolve-conflicts was added and defaults to true, I can feel safe in toggling it off forever in my ~/.emacs, knowing that it is a totally broken option that came from a desire to fix a problem that does not exist.