git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gummerer <t.gummerer@gmail.com>
To: Grzegorz Rajchman <rayman17@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [BUG] git stash pop --quiet deletes files in git 2.24.0
Date: Thu, 7 Nov 2019 18:49:12 +0000	[thread overview]
Message-ID: <20191107184912.GA3115@cat> (raw)
In-Reply-To: <CAMcnqp22tEFva4vYHYLzY83JqDHGzDbDGoUod21Dhtnvv=h_Pg@mail.gmail.com>

On 11/07, Grzegorz Rajchman wrote:
> Hi, this is the first time I report an issue in git so I hope I'm
> doing it right.

Thanks for the report.  You are indeed doing this right, and the
included reproduction is very helpful.

I broke this in 34933d0eff ("stash: make sure to write refreshed
cache", 2019-09-11), which wasn't caught by the tests, nor by me as I
don't use the --quiet flag normally.

Below is a fix for this, but I want to understand the problem a bit
better and write some tests before sending a patch.

index ab30d1e920..2dd9c9bbcd 100644
--- a/builtin/stash.c
+++ b/builtin/stash.c
@@ -473,22 +473,20 @@ static int do_apply_stash(const char *prefix, struct stash_info *info,
 
                if (reset_tree(&c_tree, 0, 1)) {
                        strbuf_release(&out);
                        return -1;
                }
 
                ret = update_index(&out);
                strbuf_release(&out);
                if (ret)
                        return -1;
-
-               discard_cache();
        }
 
        if (quiet) {
                if (refresh_and_write_cache(REFRESH_QUIET, 0, 0))
                        warning("could not refresh index");
        } else {
                struct child_process cp = CHILD_PROCESS_INIT;
 
                /*
                 * Status is quite simple and could be replaced with calls to


> I have experienced some unexpected behaviour with git stash pop
> --quiet in git 2.24.0. I use stash in a pre-commit hook script. In it,
> I stash non-staged changes to keep the working directory clean while
> running some linters, then I restore the stash by running pop, but
> after the recent git update I noticed that it stages all previously
> checked files as deleted.
> 
> Steps to reproduce:
> 
>   mkdir test-git-stash
>   cd test-git-stash/
>   git init
>   echo foo > foo.txt
>   git add . && git commit -m 'init'
>   echo bar > foo.txt
>   git stash save --quiet --include-untracked --keep-index
>   git stash pop --quiet
>   git status
> 
> This will unexpectedly output:
> 
>   On branch master
>   Changes to be committed:
>     (use "git restore --staged <file>..." to unstage)
>       deleted:    foo.txt
> 
>   Untracked files:
>     (use "git add <file>..." to include in what will be committed)
>       foo.txt
> 
> Notice that foo.txt was staged as deleted whilst still being present
> on the disk.
> 
> However, if I remove --quiet flag from stash pop:
> 
>   git restore --staged foo.txt
>   git stash save --quiet --include-untracked --keep-index
>   git stash pop
>   git status
> 
> Then it works as expected. It used to work as expected in git prior to 2.24.0
> 
> My OS is Ubuntu 19.04.

  reply	other threads:[~2019-11-07 18:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-07 10:36 [BUG] git stash pop --quiet deletes files in git 2.24.0 Grzegorz Rajchman
2019-11-07 18:49 ` Thomas Gummerer [this message]
2019-11-08  2:32   ` Junio C Hamano
2019-11-08 16:59     ` Thomas Gummerer
2019-11-10  6:11       ` Junio C Hamano
2019-11-11 19:56         ` Thomas Gummerer
2019-11-12  5:21           ` Junio C Hamano
2019-11-13 11:15             ` Thomas Gummerer
2019-11-13 13:31               ` Junio C Hamano
2019-11-13 15:01                 ` [PATCH v3] stash: make sure we have a valid index before writing it Thomas Gummerer
2019-11-14  2:07                   ` Junio C Hamano
2019-11-13 11:17           ` [PATCH v2 1/2] t3903: avoid git commands inside command substitution Thomas Gummerer
2019-11-13 11:17             ` [PATCH v2 2/2] stash: make sure we have a valid index before writing it Thomas Gummerer

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191107184912.GA3115@cat \
    --to=t.gummerer@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=rayman17@gmail.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.
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 NNTP newsgroup(s).