On Wed, Apr 22, 2015 at 02:35:40PM -0400, Jeff King wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
