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.
prev parent 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.