All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: John Sockwell <John@plasticcircus.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Bug report: git stash
Date: Wed, 20 Nov 2019 20:12:52 +0100	[thread overview]
Message-ID: <20191120191252.GA13575@szeder.dev> (raw)
In-Reply-To: <B173575D-E845-498A-A3E4-5AF894215475@plasticcircus.com>

On Wed, Nov 20, 2019 at 05:26:12PM +0000, John Sockwell wrote:
> > I’ve encountered unexpected behavior using the `git stash pop —quiet` after the pop the all the files in the repo are untracked.
> > 
> > My software versions: 
> >> macOS Catalina 10.15.1
> >> zsh 5.7.1
> >> git 2.24.0
> > 
> > Steps to reproduce:
> >> Create an empty repo: `mkdir /tmp/git; cd /tmp/git; git init`
> >> Commit an empty file: `touch sample-file; git add sample-file; git commit --message "Initial commit”`
> >> Modify the sample file: `echo "modification" > sample-file`
> >> Stash the dirty tree: `git stash push`
> >> Pop the stash: `git stash pop` — working tree returned to dirty state with modified: sample file
> >> Stash the dirty tree again: `git stash push`
> >> Pop the stash using the —quiet option: `git stash pop —quiet`
> > 
> > Expected result: Same behavior as without the —quiet option. Working tree to again be returned to dirty state with modified: sample-file
> >> `git status`
> >> On branch master
> >> Changes not staged for commit:
> >>   (use "git add <file>..." to update what will be committed)
> >>   (use "git restore <file>..." to discard changes in working directory)
> >> 	modified:   sample-file
> >> 
> >> no changes added to commit (use "git add" and/or "git commit -a”)
> >> 
> > Actual result: working tree is dirty with a different set of changes deleted: sample-file, untracked files: sample-file
> >> `git status`
> >> On branch master
> >> Changes to be committed:
> >>   (use "git restore --staged <file>..." to unstage)
> >> 	deleted:    sample-file
> >> 
> >> Untracked files:
> >>   (use "git add <file>..." to include in what will be committed)
> >> 	sample-file

Thanks for the bug report.  It's a known issue that was indeed
introduced in v2.24.0, and we already have a fix for it in commit
df53c80822 (stash: make sure we have a valid index before writing it,
2019-11-13).

The previous bug report and related discussion can be found at:

  https://public-inbox.org/git/20191113150136.GB3047@cat/T/#u

Perhaps the fix will make it to a v2.24.0.1 soon-ish.


      reply	other threads:[~2019-11-20 19:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3F47D50C-4E1C-4BAC-AFB9-3E908B123278@plasticcircus.com>
     [not found] ` <DB3F5927-76A4-43F1-8A09-EEB7D0B6F720@plasticcircus.com>
2019-11-20 17:26   ` Bug report: git stash John Sockwell
2019-11-20 19:12     ` SZEDER Gábor [this message]

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=20191120191252.GA13575@szeder.dev \
    --to=szeder.dev@gmail.com \
    --cc=John@plasticcircus.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.