Re: How do I resolve conflict after popping stash without adding the file to index?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 22, 2015, 19:45 UTC
Message-ID: <xmqq8udkdk1a.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150422183540.GC3535@peff.net>

Jeff King <peff@peff.net> writes:

> Ironically, the message before e0e2a9c actually recommends staging
> changes before applying the stash, which would lead to this exact
> situation!

The ancient history is hazy to me, but did we fall back to three-way merge in old days (or did anything to the index for that matter), I wonder? In a world "git stash apply" only applied the change to the working tree via "git apply", that old recommendation would make perfect sense.

But obviously we do not live in such a world right now. And because we are doing "merge-recursive", we should insist on a clean index; otherwise there is no way to "undo" its effect without losing the changes by the end-user.

Show 11 quoted lines

> So I think the most trivial patch is:
>
> diff --git a/git-stash.sh b/git-stash.sh
> index d4cf818..f1865c9 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -442,6 +442,7 @@ apply_stash () {
>  	assert_stash_like "$@"
>  
>  	git update-index -q --refresh || die "$(gettext "unable to refresh index")"
> +	git diff-index --cached HEAD || die "dirty index; cannot apply stash"

Yes, that makes sense. The original report from Dmitry was triggering the safety from one line above and "git stash pop" doing the right thing by refusing to touch the index with unresolved mergy operation before doing anything, and with this additional safety, we would make it even safer from people who do "git add" and then "git stash pop" (which is somewhat strange thing to do, given that "stash" was designed for "stash to save away; do other things; come back to the original commit state that is 'reset --hard' clean; unstash" sequence in the first place).

Show 6 quoted lines

>  	# current index state
>  	c_tree=$(git write-tree) ||
>
> but it makes me wonder if somebody would find it annoying that they
> cannot apply a stash into their work-in-progress (i.e., it _might_ cause
> annoyance, but most of the time it will be convenient to do so).

They can always do "git stash show -p stash@{n} | git apply" if they want to build changes incrementally X-<, but it would be annoying.

> So probably we'd want to refactor that into two separate functions, and
> only call the require_clean_index part.

Hmph, but what would that helper do, other than a single "diff-index --quiet --cached HEAD" call?