git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Apr 22, 2015, 19:29 UTC
Message-ID
<20150422192948.GA27656@peff.net>
In-Reply-To
<20150422183540.GC3535@peff.net>
On Wed, Apr 22, 2015 at 02:35:40PM -0400, Jeff King wrote:
Show 20 quoted lines
> Ironically, the message before e0e2a9c actually recommends staging
> changes before applying the stash, which would lead to this exact
> situation! 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"
>  
>  	# 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).

It does actually fail a test in t3903, but I think that test just incidentally had a dirty index, and didn't care about that particular feature.

> We also have require_clean_work_tree() in git-sh-setup.sh. We definitely
> don't want the first half of that, but we do want the diff-index check.
> So probably we'd want to refactor that into two separate functions, and
> only call the require_clean_index part.

This turned out to be more work than it was worth. Most of the effort in that function is about adjusting the messages to handle the cases when either or both of the working tree and index are dirty. I did pick up the useful bits from there, though:

  - use --quiet to suppress output and so that the exit code actually
    matters
  - use "--" to disambiguate the ref
  - I didn't pick up the `rev-parse HEAD` call. I don't think it's
    necessary (i.e., diff-index should barf for us if it can't read
    HEAD).
Here are the patches.
  [1/3]: t3903: stop hard-coding commit sha1s
  [2/3]: t3903: avoid applying onto dirty index
  [3/3]: stash: require a clean index to apply
-Peff
Previous: Jeff KingNext: Jeff King
Message 9 of 14 in “How do I resolve conflict after popping stash without adding the file to index?”
  1. Dmitry GutovApr 20, 2015
  2. Junio C HamanoApr 20, 2015
  3. Dmitry GutovApr 20, 2015
  4. Jeff KingApr 21, 2015
  5. Dmitry GutovApr 21, 2015
  6. Jeff KingApr 21, 2015
  7. Junio C HamanoApr 22, 2015
  8. Jeff KingApr 22, 2015
  9. Jeff KingApr 22, 2015
  10. 1/3 t3903: stop hard-coding commit sha1sJeff King, Apr 22, 2015
  11. 2/3 t3903: avoid applying onto dirty indexJeff King, Apr 22, 2015
  12. 3/3 stash: require a clean index to applyJeff King, Apr 22, 2015
  13. Junio C HamanoApr 22, 2015
  14. Jeff KingApr 22, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.